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PREFACE 

This  report  describes  the  work  performed,  the  results  obtained,  and  the  conclusions  reached  during 
the  Common  Ada  Missile  Packages  Phase-2  (CAMP-2)  contract  (F08635-86-C-0025).  This  work  was 
performed  by  the  Software  and  Information  Systems  Department  of  the  McDonnell  Douglas  Astronautics 
Company.  St.  Louis,  Missouri  (MDAC-STL),  and  was  sponsored  by  the  United  States  Air  Force  Ar¬ 
mament  Laboratory  (FXG)  at  Eglin  Air  Force  Base,  Florida.  This  contract  was  performed  between  Sep¬ 
tember  1985,  and  March  1988. 

The  MDAC-STL  CAMP  program  manager  was: 

Dr.  Daniel  G.  McNicholl 
Technology  Branch 

Software  and  Information  Systems  Department 
McDonnell  Douglas  Astronautics  Company 
P.O.  Box  516 
St.  Louis,  Missouri  63166 

The  AFATL  CAMP  program  manager  was: 

Christine  M.  Anderson 

Guidance  and  Control  Branch 

Aeromechanics  Division 

Air  Force  Armament  Laboratory 

Eglin  Air  Force  Base,  Florida  32542-5434 

This  report  consists  of  three  volumes.  Volume  I  contains  information  on  the  development  of  the 
CAMP  parts  and  the  Paris  Composition  System.  Volume  II  contains  the  results  of  the  11th  Missile 
Application  development.  Volume  III  contains  the  results  of  the  CAMP  Armonics  Benchmarks  Suite 

development. 

Commercial  hardware  and  software  products  mentioned  in  this  report  are  sometimes  identified  by 
manufacturer  or  brand  name.  Such  mention  is  necessary  for  an  understanding  of  the  R  &  D  effort,  but 
does  not  constitute  endorsement  of  these  items  by  the  U  S.  Government. 

ACKNOWLEDGEMENT 

Special  thanks  to  the  Armament  Division  Deputy  for  Armament  Control  Office;  to  the  Software 
Technology  for  Adaptable.  Reliable  Systems  (STARS)  Joint  Program  Office;  to  the  Ada  Joint  Program 
Office  (AJPO);  and  to  the  Air  Force  Electronic  Systems  Division,  Computer  Resource  Management 


TRADEMARKS 


The  following  table  lists  the  trademarks  used  throughout  this  document: 


TRADEMARK 

TRADEMARK  OF 

ACT 

Advanced  Computer  Techniques 

ART 

Inference  Corporation 

ART  Studio 

Inference  Corporation 

CMS 

Digital  Equipment  Corporation 

DEC 

Digital  Equipment  Corporation 

Mikros 

Mikros,  Inc. 

Oracle 

Oracle  Corporation 

Scribe 

Scribe  Systems 

Symbolics 

Symbolics,  Inc. 

Symbolics  3620 

Symbolics,  Inc. 

TLD 

TLD  Systems  Ltd 

VAX 

Digital  Equipment  Corporation 

VMS 

Digital  Equipment  Corporation 

Table  of  Contents 


Section  Title  Page 

I  INTRODUCTION  .  1 

1 .  Purpose .  1 

2.  Goals  and  Objectives  .  1 

3.  Deliverables  .  2 

4.  Organization  of  the  Report .  2 

II  DEVELOPMENT  AND  TESTING  OF  1 1 TH  MISSILE  APPLICATION  .  3 

1.  What  Is  the  11th  Missile?  .  3 

2.  Eleventh  Missile  Development .  5 

a.  Requirements  Development .  5 

( 1 )  Navigation  Requirements .  6 

(2)  Guidance  Requirements .  6 

(3)  Interface  Requirements .  6 

b.  Top-Level  Design .  6 

(1)  Object-Oriented  Design  .  6 

(2)  The  Architectural  Design  Process .  9 

c.  Detailed  Design  and  Code  .  9 

d.  Unit  and  Component  Level  Test  Methods .  12 

(1)  Unit  Test  Approach .  12 

(2)  Process  .  14 

e.  Integration  and  Hardware-in-the-Loop  Tests .  15 

f.  Tools  .  16 

(1)  Requirements  Mapping  Tools .  17 

(2)  Design  Visualization  Tools .  17 

(3)  Documentation  Tools .  21 

(4)  Ada  Compilers  .  21 

(5)  Test  Tools .  22 

(6)  Other  Software  Development  Tools  .  22 

(7)  Management  Tools .  24 

III  EVALUATION  OF  THE  CAMP  PARTS  AND  THEIR  USE  IN  THE  11TH  MISSILE 

APPLICATION  .  25 

1.  Productivity .  25 

2.  Parts:  Where  They  Were  Used .  29 

3.  Parts:  Used,  Modified,  Unused,  And  Why  .  33 

a.  Baseline  Version  .  33 

(1)  Parts  Modified .  33 

(2)  Parts  Not  Used  .  36 


V 


Table  of  Contents  (cont’d) 


Section  Title  Page 

b.  Tested  Version  .  37 

4.  Parts  Changed .  38 

IV  EVALUATION  OF  THE  PARTS  COMPOSITION  SYSTEM  AND  ITS  USE  IN  THE 

1 1 TH  MISSILE  APPLICATION  .  44 

1.  Productivity .  44 

2.  PCS:  Where  It  Was  Used .  45 

3.  Parts:  Used,  Modified,  Unused,  And  Why  .  46 

4.  PCS:  Problems .  46 

V  EVALUATION  OF  ADA  AND  ITS  USE  IN  THE  1 1  TH  MISSILE  APPLICATION  .  48 

1.  Effectiveness  of  Ada  for  Machine  Input/Output  -  An  Example .  48 

a.  Description  of  the  Bus  Interface  Module  (BIM)  Interface .  48 

b.  Ada  Solution  to  the  BIM  Interface .  52 

2.  Ineffectiveness  of  Ada  for  Operating  System  Interface .  54 

3.  Use  of  Optional  Features  .  58 

VI  EVALUATION  OF  AN  ADA  COMPILER  AND  ITS  USE  IN  THE  11  TH  MISSILE 

APPLICATION  .  61 

1.  Compiler  Problems  and  Solutions  .  61 

a.  History  of  Compiler  Utilization .  61 

b.  Summary  of  Problem  Reports .  62 

c.  Some  Compiler  Problems  and  Work-Arounds  .  65 

(1)  Generics  .  65 

(2)  Separate  Subunits .  66 

(3)  Parameter  Passing .  68 

(4)  Machine  Code  Patches .  68 

(5)  Memory  Utilization .  68 

2.  Compiler  Inefficiency .  76 

a.  Tasking .  76 

b.  Generics  .  78 

c.  Temporary  Data  Space .  79 

d.  Other  Causes  of  Inefficiency  .  80 

c.  Are  These  Compiler  Problems? .  80 

VII  CONCLUSIONS  AND  RECOMMENDATIONS  .  82 

1.  Conclusions .  82 

2.  Recommendations .  83 

a.  Modifications  to  Parts .  83 

vi 


Table  of  Contents  (cont’d) 


Section  Title  Page 

b.  Modifications  to  the  CAMP  PCS .  88 

c.  Suggested  Ada  Language  Improvements . 89 

Appendix  1 1th  MISSILE  USAGE  DATA  BASE .  91 

1.  Introduction  and  Background  .  91 

2.  Database  Issues .  91 

3.  Parts  Usage  and  Code  Count .  92 

References .  Ill 


vii/viU  (Blank) 


List  of  Figures 


Figure  Title  Page 

1  1  llh  Missile  Hardware  Design .  4 

2  11th  Missile  Requirements  Came  From  Several  Sources .  5 

3  Package  Kalman_Filter  Structure  Chart  .  7 

4  Legend  for  Kalman_Filter  Structure  Chart .  8 

5  NAV  Computer  Top-Level  Decomposition:  Environment .  10 

6  NAV  Computer  Top-Level  Decomposition:  Nav_Software  .  1 1 

7  Package  Alignment_Measurements .  1 3 

8  Procedure  CanceLMeasurement  .  14 

9  Test  Approach .  15 

10  Hardware  Configurations . 16 

1 1  Code  for  Three  Compilers  Combined  in  One  File .  23 

12  NAV  Computer  Parts  Usage .  30 

13  GU1D  Computer  Parts  Usage .  30 

14  Possible  New  Representation  of  Kalman  Matrix .  47 

15  BIM/1750A  Interface .  49 

16  Use  of  Interrupt  Entry .  52 

17  Example  of  Record  Representation  Clause .  53 

18  Representation  Clause  for  Variant  Record  .  55 

19  Module  Reset_Sys_Enab!e_ROM  .  56 

20  SURMOS  Interface .  56 

21  Machine  Code  Insertion .  57 

22  Forcing  a  32-bit  Access  Type  .  60 

23  Forcing  a  Fixed-Point  Representation  without  Using  'Small .  60 

24  Problem  Reports  by  Month,  "Compiler  B" .  63 

25  Cumulative  History  of  Problem  Reports,  "Compiler  B"  .  64 

26  Code  Before  Manual  Instantiation .  66 

27  Code  After  Manual  Instantiation  .  67 

28  Legend  for  Diagrams  .  69 

29  Baseline  Guid_Computer  Procedure .  70 

30  Baseline  Guidance_Operations  Package .  71 

31  Modified  Guid_Computer  Procedure  .  72 

32  Modified  Guidance_Operations  Package  .  73 

33  Section  of  Code  Before  Manual  In-lining .  75 

34  Section  of  Code  After  Manual  In-lining  .  76 

35  Saving  Stack  Space  Using  Enclosing  Procedures .  77 

ix 


List  of  Figures  (cont’d) 


Figure  Title  Page 

36  Recommended  Change  to  Matrix_Operations .  84 

37  Recommended  Change  to  Matrix_ScaIar_Operalions .  85 

38  Recommended  Change  to  Matrix_Vector_Multiply  .  86 

39  Recommended  Change  to  Malrix_Ma?rix_MuItiply  .  87 


List  of  Tables 


Table  Title  Page 

1  The  CAMP  Domain .  3 

2  Processors  and  Their  Functions .  4 

3  Unit- and  Package-Level  Test  Decision  Matrix .  12 

4  Tools  Used  by  Software  Development  Phase .  17 

5  Navigation  TLCSC  Functional  Allocation  to  Lower  Level  Computer  Software  Com¬ 
ponents  .  18 

6  NAV  Computer  Message  Map .  20 

7  11th  Missile  Effort .  26 

8  1  lth  Missile  Size  -  Parts  Method .  26 

9  11th  Missile  Productivity  -  Parts  Method .  27 

10  Effect  of  Parts  on  1  lth  Missile  Effort .  27 

1 1  Summary  of  CAMP  Parts  Usage  -  Parts  Method .  33 

1 2  Summary  of  CAMP  Parts  Used .  34 

13  CAMP  Parts  Modified  .  34 

14  Polynomial  Parts  Used  For  Trigonometric  Functions  .  35 

15  Summary  of  Parts  Not  Used  By  1 1  th  Missile .  36 

16  Parts  Incompatible  with  1 1  th  Missile  .  37 

17  Parts  Manually  Instantiated  in  Guid_Computer  .  38 

18  Parts  Manually  Instantiated  in  Nav_Computer .  39 

19  Parts  Changes  and  Enhancements  Generated  By  The  1 1  th  Missile  Development .  40 

20  1  lth  Missile  Size  -  PCS  Method .  44 

21  Estimated  Effect  of  PCS  on  1  lth  Missile  Effort .  45 

22  Summary  of  CAMP  Parts  Usage  -  PCS  Method  .  46 

23  Bus  Interface  Module  Command  Word .  49 

24  Bus  Interface  Module  Status  Word .  50 

25  Bus  Interface  Module  Initialization  Block .  51 

26  Use  of  Optional  Ada  Features  By  1  lth  Missile  .  59 

27  Problem  Reports  by  Category,  "Compiler  B" .  62 

28  Use  of  Generics  in  Baseline  and  Modified  Software .  74 

29  Separate  Subunits  and  Files  Compiled  .  74 

A-l  Parts  Usage  Fields  and  Descriptions .  91 

A-2  Parts  Usage  and  Code  Count .  93 


List  of  Acronyms 


ACS 

Ada  Compilation  System 

ACVC 

Ada  Compiler  Validation  Capability 

AdaJUG 

Ada/Jovial  Users  Group 

ADL 

Ada  Design  language 

AFATL 

Air  Force  Armament  Laboratory 

AFB 

Air  Force  Base 

AI 

Artificial  Intelligence 

AJPO 

Ada  Joint  Program  Office 

AMPEE 

Ada  Missile  Parts  Engineering  Expert  (System) 

AMR  A  AM 

Advanced  Medium  Range  Air-to-Air  Missile 

ANSI 

American  National  Standards  Institude 

APSE 

Ada  Programming  Support  Environment 

Annonics 

Armament  Electronics 

ART 

Automated  Reasoning  Tool 

ASCII 

American  Standard  Code  for  Information  Interchange 

BC 

Bus  Controller 

BDT 

Basic  Data  Types 

BIM 

Bus  Interface  Module 

CAD/CAM 

Computer-Aid  Design/Compuler-Aided  Manufacturing 

CAMP 

Common  Ada  Missile  Packages 

CCCB 

Configuration  Change  Control  Board 

CDRL 

Contractual  Data  Requirements  List 

CMS 

Code  Management  System 

ConvFactois 

Conversion_Factors  (TLtSC) 

CPDS 

Computer  Program  Development  Specification 

CPPS 

Computer  Program  Product  Specification 

CSC 

Computer  Software  Component 

CSCI 

Computer  Software  Configuration  Item 

CVMA 

Coordinate_Vector_Matrix_AJgebra  (TLCSC) 

DACS 

Defense  Analysis  Center  for  Software 

DBMS 

Data  Base  Management  System 

DCL 

DIGITAL  Command  Language 

DDD 

Detailed  Design  Document 

DEC 

Digital  Equipment  Corporation 

DMA 

Direct  Memory  Access 

DoD 

Department  of  Defense 

xii 


DoD-STD 

Department  of  Defense  Standard 

DPSS 

Digital  Processing  Subsystem 

DSR 

Digital  Standard  Runoff 

DTM 

DEC  /Test  Manager 

FMS 

Forms  Management  System 

FORTRAN 

FORmula  TRANsIation 

GPMath 

General_Purpose_Math  (TLCSC) 

HOL 

Higher-Order  Language 

Hr 

Hour 

I/O 

Input/Output 

ISA 

Inertial  Sensor  Assembly 

JOVIAL 

Jules  Own  Version  of  International  Algebraic  Language 

LISP 

List  Processing  (language) 

LLCSC 

Lower  Level  Computer  Software  Component 

LOC 

Lines  of  Code 

MDAC 

McDonnell  Douglas  Astronautics  Company 

MDAC-HB 

McDonnell  Douglas  Astronautics  Company  -  Huntington  Beach 

MDAC-STL 

McDonnell  Douglas  Astronautics  Company  -  St.  Louis 

MDC 

McDonnell  Douglas  Corporation 

MIL-STD 

Military  Standard 

MRASM 

Medium  Range  Air-to-Surface  Missile 

NM 

Nautical  Miles 

NPNav 

North_Pointing_Navigation_Parts  (TLCSC) 

OCU 

Operator  Control  Unit 

Opns 

Operations 

PC 

Personal  Computer 

PCS 

Parts  Composition  System 

PDL 

Program  Design  Language 

R&D 

Research  and  Development 

RT 

Remote  Terminal 

RTE 

Real-Time  Embedded 

SDF 

Software  Development  File 

SDI 

Strategic  Defense  Initiative 

SDN 

Software  Development  Notebook 

SDR 

Software  Discrepancy  Report 

SEAFAC 

System  Engineering  Avionics  Facility 

SEI 

Software  Engineering  Institute 

xiii 


SEP/S  CP 

Software  Enhancement  Proposal/SoL  .vare  Change  Proposal 

SI  0  Ada 

Special  Interest  Group  on  Ada 

SRS 

Software  Requirements  Specification 

STARS 

Software  Technology  for  Adaptable,  Reliable  Systems 

stmt 

statement 

SURMOS 

Stait-Up  Real-time  Multi-tasking  Operating  System 

TLCSC 

Top-Level  Computer  Software  Component 

TLDD 

Top-Level  Design  Document 

UnivConst 

Universal_Constants  (TLCSC) 

VAX 

Virtual  Address  Extension 

VMS 

Virtual  Memory  System 

WOS72 

World  Geodetic  System,  1972 

xiv 


SECTION  I 


INTRODUCTION 


1.  PURPOSE 

This  report  contains  a  description  of  the  work  performed,  the  results  achieved,  and  the  lessons 
learned  on  the  11th  Missile  Application  of  the  Common  Ada  Missile  Packages  Phase  2  (CAMP-2) 
project.  CAMP-2  was  a  multi-year  research  effort  in  which  the  McDonnell  Douglas  Astronautics 
Company-St.  Louis  (MDAC-STL)  demonstrated  the  feasibility  and  value  of  reusable  Ada  software  parts 
in  embedded,  real-time,  mission-critical,  DoD  applications.  This  was  accomplished  by  (a)  building  a 
library  of  efficient  and  reusable  Ada  parts  for  missile  flight  applications,  (b)  building  a  prototype  parts 
composition  system  (PCS),  and  (c)  testing  the  parts  and  the  PCS  by  using  them  on  an  actual  missile 
application  (the  11th  Missile). 

The  CAMP  project  has  been  sponsored  by  the  Air  Force  Armament  Laboratory  at  Eglin  Air  Force 
Base,  and  partially  funded  by  the  Air  Force  Armament  Division;  the  DoD  Software  Technology  for 
Adaptable,  Reliable  Systems  (STARS)  Program  Office;  and  the  Air  Force  Electronic  Systems  Division. 
The  Ada  Joint  Program  Office  (AJPO)  sponsored  the  initial  distribution  of  CAMP  Ada  parts  to  120 
Government  agencies  and  contractors.  This  software  is  now  available  through  the  Air  Force  Defense 
Analysis  Center  for  Software  (DACS)  at  Griffiss  Air  Force  Base,  New  York. 

2.  GOALS  AND  OBJECTIVES 

The  overall  goal  of  CAMP-2  was  to  demonstrate  the  technical  feasibility  and  value  of  reusable  Ada 
missile  parts  and  a  PCS  by  building  and  using  them  on  a  realistic  application.  The  11th  Missile  Applica¬ 
tion  involved  the  construction  of  an  actual  missile  application  using  the  Ada  parts  and  the  PCS,  and 
testing  of  the  developed  system  in  a  MDL-STD-1750A  hardware-in-the-loop  simulation.  The  initial  goals 
of  the  application  are  enumerated  below. 

1.  Construct  a  complete  missile  application  using  CAMP  parts  and  the  PCS,  and  test  it  in  a  17S0A 
hardware-in-the-loop  simulation. 

2.  Evaluate  the  suitability  of  the  CAMP  parts  and  the  PCS  for  real-time  embedded  missile  applica¬ 
tions. 

3.  Test  the  CAMP  parts  and  the  PCS.  and  recommend  corrections  and  improvements. 

4.  Quantify  the  productivity  improvement  attributable  to  the  use  of  CAMP  parts  and  the  PCS. 

Although  not  explicitly  staled  as  goals,  the  1  llh  Missile  Application  also  served  as  the  basis  for  (1) 
an  evaluation  of  the  suitability  of  Ada  for  real-time  embedded  missile  applications,  and  (2)  an  evaluation 
of  the  suitability  of  an  Ada/1750A  compiler  for  real-time  embedded  applications. 
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3.  DELIVERABLES 


The  deliverable  products  of  the  1 1th  Missile  Application  were: 

1 .  Software  Requirements  Specification:  The  requirements  of  the  missile  application  documented  in 
accordance  with  DOD-STD-2167,  AFATL-TR-88-24,  Volume  1. 

2.  Top-Level  Design  Document:  The  architectural  design  for  the  1 1th  Missile  system  documented  in 
accordance  with  DOD-STD-2167,  AFATL-TR-88-24,  Volume  2. 

3.  Test  Plan:  The  plan  by  which  the  11th  Missile  system  was  tested  in  accordance  with  DOD- 
STD-2167,  AFATL-TR-88-22. 

4.  Test  Report:  The  results  of  testing  the  application  in  accordance  with  DOD-STD-2167.  This 
includes  an  evaluation  of  the  1 1th  Missile  development. 

4.  ORGANIZATION  OF  THE  REPORT 

Due  to  the  large  amount  of  data  to  be  discussed  in  this  report,  it  has  been  divided  into  three  volumes. 
The  remaining  sections  of  Voiume  II  are  organized  as  follows. 

•  Section  II  describes  the  development  and  testing  of  the  1 1th  Missile  Application. 

•  Section  III  evaluates  the  CAMP  parts  and  their  suitability  for  real-time  embedded  missile  applica¬ 
tions. 

•  Section  IV  evaluates  the  Kalman  Filter  Constructor,  which  is  part  of  the  CAMP  PCS,  and  its 
suitability  for  real-time  embedded  missile  applications. 

•  Section  V  evaluates  the  suitability  and  effectiveness  of  the  Ada  language  for  real-time  embedded 
missile  applications. 

•  Section  VI  evaluates  the  suitability  of  an  Ada/1750A  compiler  for  real-time  embedded  missile 
applications  and  shows  how  to  "work  around"  the  problems  encountered. 

•  Section  VII  contains  conclusions  and  recommendations. 

Volume  I  describes  the  development  and  testing  of  the  CAMP  parts  and  the  PCS.  Volume  HI 
describes  the  development  and  testing  of  the  Armonics  Benchmarks. 
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SECTION  II 

DEVELOPMENT  AND  TESTING  OF  IITH  MISSILE  APPLICATION 


I.  WHAT  IS  THE  I ITH  MISSILE? 

The  CAMP  parts  and  parts  composition  system  (PCS)  were  designed  and  implemented  following  a 
domain  analysis  of  ten  missiles  (see  Table  1).  To  test  the  parts  and  PCS  in  a  realistic  setting,  an  "11th 
Missile"  was  held  in  reserve  and  a  portion  of  its  software  was  implemented  using  them. 

TABLE  1.  THE  CAMP  DOMAIN 


1 .  Flight  Software  for  the  Medium  Range  Air-to-Surface  Mlaaile  (AOM-  I09H) 

2.  Flight  Software  for  the  Medium  Range  Air-to-Surface  Mlaaile  (AOM-  I09L) 

3.  Strapdown  Inertial  Navigation  Program  for  the  Unaided  Tactical  Ouidance 
Project 

4.  Ouidance  and  Navigation  Program  for  the  Midcourse  Ouidance  Demonstra¬ 
tion 

5.  Flight  Software  for  the  Tomahawk  Land  Attack  Miasile  (BOM- IOTA) 

6.  Flight  Software  for  the  Tomahawk  Anti-Ship  Missile  (BGM-IOTB) 

7.  Flight  Software  for  the  Tomahawk  Land  Attack  Missile  (BOM-IOTC) 

8.  Flight  Software  for  the  Tomahawk  Land  Attack  Miasile  (BOM- 1090) 

9.  Flight  Software  for  the  Harpoon  Misaile  (Block  1C) 

10.  Safeguard  Spartan  Missile 


The  Uth  Missile  Application  was  based  on  a  cruise  missile  application  that  was  originally  im¬ 
plemented  in  JOVIAL  J73.  The  original  application  had  five  MIL-STD-1750A  processors  and  an  Inertial 
Sensor  Assembly  (LSA),  which  communicate  by  means  of  a  MIL-STD-1533B  data  bus  (see  Figure  1). 
The  shared  memory  contained  terrain  altitude  data.  The  processors  and  their  primary  functions  are  shown 
in  Table  2.  In  addition,  all  processors  were  programmed  to  perform  the  following  support  functions: 

•  Restart  the  application  program 

•  Return  control  to  start-up  ROM 

•  Communicate  via  the  1553B  bus 

•  Issue  periodic  status  messages 

The  1 1th  Missile  Application  is  a  re-implementation  (starting  with  a  new  requirements  specification) 
of  the  navigation,  ground  alignment,  Kalman  filtering,  ISA  interface,  lateral  guidance,  lateral-directional 
autopilot,  and  support  functions  of  the  original  software.  The  navigation,  Kalman  filtering,  lateral 
guidance,  and  lateral-directional  autopilot  were  chosen  because  there  were  CAMP  parts  to  support  those 
functions.  The  other  functions  were  required  to  complete  a  functioning  computer  program. 
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11th  Miisil* 
System 


Figure  1.  1 1th  Missile  Hardware  Design 


TABLE  2.  PROCESSORS  AND  THEIR  FUNCTIONS 


Processor 

Functions 

Control 

Communicates  with  operator  console 

Downloads,  starts,  and  stops  software  in  ill  other  machine! 

Mode  logic 

Navigation 

Wander-azimuth  navigation 

Transfer  alignment 

Ground  alignment 

21-alale  Kalman  filter 

Start  up,  teat,  and  communicate  with  ISA 

Guidance 

Waypoint-steering  lateral  guidance 

Vertical  guidance 

Lateral-directional  autopilot 

Correlation 

Dedicated  to  Terrain  Profile  Matching 

Sensor 

Controls  sensor  system  hardware 

Two  versions  of  (he  1 1th  Missile  Application  were  written.  The  first  version  ("Parts  Method")  was 
written  using  the  CAMP  parts,  but  not  the  CAMP  PCS.  The  second  version  ("PCS  Method")  used  the 
PCS  to  generate  Kalman  filter  code.  The  PCS  Method  implementation  was  not  a  complete  rewrite  of  the 
code;  rather,  the  PCS-generated  Kalman  filter  code  was  integrated  with  the  rest  of  the  Parts  Method  code 
and  unit  tested. 

2.  ELEVENTH  MISSILE  DEVELOPMENT 
a.  Requirements  Development 

The  11th  Missile  requirements  were  developed  in  accordance  with  DOD-STD-2167,  and 
documented  in  a  Software  Requirements  Specification  (SRS).  This  specification  combined  elements  of 
the  existing  application's  navigation,  guidance,  and  interface  requirements  (see  Figure  2). 


NAV  GUID  Interface 


Figure  2.  1 1th  Missile  Requirements  Came  From  Several  Sources 
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( 1 )  Navigation  Requirements 

The  11th  Missile  navigation  requirements  came  from  several  sources.  The  existing 
application’s  navigation  requirements  were  documented  in  a  MIL-STD-1679  Computer  Program 
Development  Specification  (CPDS),  but  it  was  badly  out-of-date;  it  served  primarily  as  an  outline  of  the 
high-level  requirements.  There  was  also  a  MIL-STD-1679  Computer  Program  Product  Specification 
(CPPS),  which  included  Ada  Design  Language  (ADL)  and  which  was  more  nearly  up-to-date.  Interviews 
with  the  original  software  developers  were  necessary  to  determine  which  requirements  had  changed  since 
the  CPPS;  in  these  cases,  the  requirements  were  abstracted  from  the  updated  ADL  or,  occasionally,  from 
the  JOVIAL  code. 

(2)  Guidance  Requirements 

The  guidance  requirements  for  the  existing  application  were  specified  in  a  MIL-STD-483 
B-5  development  specification.  The  lateral  guidance  and  lateral-directional  autopilot  algorithms  were 
reused  from  the  Medium  Range  Air-to-Surface  Missile  (MRASM)  program,  therefore,  these  requirements 
were  stable  and  the  specification  was  up-to-date  and  complete. 

The  1 1th  Missile  team  discovered  an  error  in  the  autopilot  requirements  while  developing 
the  open-loop  integration  test  for  the  Guid  Computer.  The  problem  was  referred  to  the  requirements 
group  for  the  existing  application;  they  verified  the  error  and  corrected  their  requirements  specification. 
The  CAMP  project  corrected  the  1 1th  Missile  SRS  to  conform  to  the  revised  requirements. 

(3)  Interface  Requirements 

The  1553B  bus  protocols  and  the  formats  of  all  bus  messages  were  specified  in  a  database 
maintained  by  the  original  application.  That  project  used  the  database  to  automatically  generate  the 
JOVIAL  code  that  specified  the  message  formats  for  the  application  programs,  the  FORTRAN  code  for 
the  real-time-simulation  software,  and  the  interface  requirements  specification.  The  11th  Missile  team 
used  the  database  to  get  up-to-date  message  specifications  and  change  notices. 

b.  Top-Level  Design 

( I )  Object-Oriented  Design 

In  an  object-oriented  design,  the  requirements  are  functionally  decomposed  and  assigned 
to  Ada  packages.  There  may  be  several  levels  of  decomposition,  which  generally  correspond  to  nested 
Ada  packages. 

In  the  1 1th  Missile  implementation  of  this  method,  tasks  are  subsidiary  to  packages.  Tasks 
were  generally  not  defined  in  a  high-level  package  specification.  If  a  task  had  to  be  invoked  from  outside 
the  high-level  package,  an  interface  procedure  to  call  the  task  was  provided.  Tasks  were  used  primarily 
for  control;  they  called  on  packages  to  execute  the  controlled  functions.  A  good  example  of  this  type  of 
design  is  the  Kalman_Filter  package  (see  Figures  3  and  4). 
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Figure  4.  Legend  for  Kalman_Fiiler  Structure  Chart 


This  philosophy  was  not  always  followed.  For  example,  the  BIM_Interface  package  was 
written  before  these  design  decisions  were  made,  and  contains  a  large  task  which  is  directly  visible  and 
which  does  its  own  processing. 

Tasks  cannot  be  completely  ignored  at  the  system  level,  however.  The  architectural  design 
had  to  specify  the  processing  priority  of  each  task. 
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(2)  The  Architectural  Design  Process 

In  this  section,  the  Navigation  Processor  design  serves  as  an  example  of  the  architectural 
design  process.  The  two  major  LLCSCs  of  the  Navigation  TLCSC  are  Environment  and  Nav_Software 
(see  Figures  5  and  6).  The  Environment  LLCSC  provides  the  interface  to  all  external  devices,  while 
NavJSoflware  performs  the  navigation,  alignment,  quaternions,  and  Kalman  filtering  functions. 

The  first  step  in  the  architectural  design  was  to  go  through  the  SRS  and  determine  all  the 
places  where  CAMP  parts  could  be  used.  An  annotated  copy  of  the  SRS  showed  where  each  part  applied. 
The  resulting  parts  list  was  used  to  drive  the  architectural  and  detailed  designs,  and  maximize  reuse  of 
existing  parts. 

The  next  step  was  to  "rough  out"  the  decomposition  diagram  (see  Figures  5  and  6),  struc¬ 
ture  charts,  and  the  Ada  package  specifications.  See  Figure  3  for  a  sample  structure  chart.  Different 
approaches  were  used  for  the  two  major  LLCSCs.  The  Environment  LLCSC  was  implemented  as  a 
single  package;  the  Nav_Soflware  LLCSC  was  implemented  as  five  packages,  since  a  single  package 
would  have  been  loo  large. 

The  top-level  design  went  through  sev.  I  iterations.  In  general,  each  iteration  hid  more 
data,  i.e.  material  moved  from  the  package  specification  to  the  body.  Also,  as  the  design  developed, 
lower-level  packages  were  created  and  the  required  functions  were  mapped  to  them.  The  end  result  of 
this  process  was  Ada  code  for  the  package  and  task  specifications,  skeleton  Ada  code  for  the  (ask  bodies, 
the  top-level  decomposition  diagram  (see  Figures  5  and  6).  and  a  series  of  structure  charts. 

The  architecture  was  informally  reviewed  by  the  design  group  as  it  developed.  The  CAMP 
Program  Manager  reviewed  the  architecture  twice;  these  reviews  concentrated  on  the  decomposition 
diagram  and  the  structure  charts.  Formal  walkthroughs  of  the  high-level  Ada  code  followed  the  final 
management  review. 

c.  Detailed  Design  and  Code 

Detailed  design  and  coding  were  combined  into  one  phase.  In  some  respects  this  phase  was  a 
continuation  of  the  top-level  design  process. 

Each  high-level  package  was  assigned  to  a  single  designer,  who  was  responsible  for  the  detailed 
design,  code,  and  headers.  All  design/code  was  walked  through  by  the  entire  11th  Missile  team.  There 
was  at  least  one  walkthrough  for  each  package;  the  larger  packages  (e.g.,  Environment,  Kalman_Filter) 
were  broken  down  and  underwent  several  walkthroughs.  The  walktliroughs  sought  to  ensure  that  the  code 
met  the  requirements,  interfaced  properly  with  other  code,  conformed  to  project  standards,  and  had  com¬ 
plete  headers. 
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Figure  5.  NAV  Computer  Top-Level  Decomposition: 


F  if  lire  6.  NAV  Computer 


d.  Unit  and  Component  Level  Test  Methods 

In  general,  the  1 1  th  Missile  team  tested  both  units  and  packages  (components).  Usually  unh¬ 
and  package-level  tests  were  separate,  but  occasionally  they  were  combined  or  the  package-level  test  was 
skipped.  Table  3  presents  the  decision  matrix  that  was  used  to  determine  the  level  of  testing  that  was 
required. 


TABLE  3.  UNIT-  AND  PACKAGE-LEVEL  TEST  DECISION  MATRIX 


1 

Cu* 

1 

1  1  1 

2 

3  1 

4 

5 

1 

(Condition 

1  Unit 

Staple 

Staple 

Cosplax 

Coaplax 

|  Interaction 

None 

Single 

Ceaplex 

Staple 

Coaplax 

| Toots  Required 

|  Unit 

T 

Pert  of 

r 

y 

package 

Coe  bine 

tMt 

|  Package 

N 

T 

Pert  of 

T 

unit 

teste 

Package-level  testing  was  not  required  if  there  was  no  interaction  between  the  units  in  the 
package.  For  example,  Kalman_Types  is  a  collection  of  data  type  definitions  and  operators;  no  data  is 
stored  in  the  package  body  and  the  units  do  not  invoke  each  other. 

If  the  units  and  the  interactions  between  them  were  both  simple,  the  unit  tests  were  folded  into 
the  package-level  test  (e.g.,  Alignment_Measurements)  or  the  unit  tests  covered  the  package-level  test 
requirements  (e.g..  Quaternions). 

If  the  units  were  complex,  then  unit-level  tests  were  always  required.  If  the  unit  interactions 
were  simple,  the  package-level  test  requirements  could  be  covered  by  the  unit  tests  (e.g.,  BIM_Interface); 
if  complex,  a  separate  package-level  test  was  required  (e.g.,  Kalman_Filter). 

The  CAMP  parts  were  assumed  to  be  correct  and  were  not  tested  separately.  They  were  tested 
indirectly  as  part  of  the  units  that  invoked  them. 

(1)  Unit  Test  Approach 

The  11th  Missile  team  designed  unit  tests  to  cover  both  white  box  and  black  box  view¬ 
points.  A  white  box  test  is  designed  with  knowledge  of  the  unit’s  structure.  The  test  cases  are  set  up  to 
exercise  all  paths  through  the  unit  and  to  invoke  all  branch  conditions.  A  black  box  test  is  a  functional 
test  that  assume s  nothing  about  the  unit’s  internal  structure.  It  passes  in  a  representative  sample  of  input 
data  and  checks  to  see  if  the  output  is  as  expected.  The  Alignment_Measurements  package  will  be  used 
to  illustrate  these  two  approaches  to  unit  testing. 

The  Alignment_Measurements  package  (see  Figure  7)  takes  a  sequence  of  integrated 
velocities  from  the  navigator,  keeps  and  corrects  running  sums  of  them,  and  periodically  formats  the  sums 
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into  measurements  and  sends  them  to  package  Kalman_Filter.  Calls  to  control  procedures  (Initialize,  Set_ 
Measurement_Time,  and  Cance!_Measurement)  initialize  the  package,  specify  when  a  measurement  is  to 
be  sent  to  Kalinan_Filter,  and  occasionally  cancel  a  measurement.  Integrate,  Put_Reference_Velocily_ 
Integrals,  and  Apply_Kalman_Position_Corrections  receive  data  needed  to  compute  or  correct  the 
integrated-velocity  sums.  Get_Integrals  returns  the  current  integrated-velocity  sums. 


with  N»v_Conput«r_D»t*_Typ«»; 
ptakaga  Aligrw«nt__M«af uranant  •  la 

paokaga  NCDT  ranaati  Nav_Con^utar_Data_Typaa ; 

procadura  Znltlallsa  (Inltlal_Tlaa  :  In  NCDT . Saoonda  ; 

Rafaranaa_Altituda  :  in  NCDT . F««t_FP ; 

Valoelty  :  In  NCDT . Valooity_Vaotora ) ; 

procadura  Intagrata  (Eff_Tlma_Of_Incr_Data  :  In  NCDT .  Saoonda ; 

Valoelty  :  in  NCDT . Valooity_Vaotora ; 

JUtituda  :  in  NCDT .  raat_H»7; 

prooadura  Put_Ra£aranea_Val oci ty_Int agral a 

(X_Valoolty_IntagraI  :  In  NCDT .  TnatJTP ; 
T_Valoaity_Intagral  :  in  NCDT . F««t_FP ) ; 

procadura  Apply_Kaljaan_Poaition_Corraution 

(Pouition_Error_X  :  in  NCDT.Earth_Poaltlon_Radlana; 
Poaltion_Error_T  :  in  NCDT.Earth_Poaltion_Radl«na) ; 

prooadura  Oat_Intagrala  (Intagratad_Val_X  :  out  NCDT.raat_VP; 

Intagratad_Val~T  :  out  NCDT . Faat_FP )  ; 

procadura  9at_Maaauraaaant_Tljaa  (Tima  :  in  NCDT.  Saoonda)  ; 

procadura  Cancal_Maaauraaaant; 

and  Alignmant_MaaauraBanta; 


Figure  7.  Package  Alignmenl_Measurements 


A  black  box  test  would  invoke  the  package  with  a  sequence  of  control  and  dat  t  calls, 
verify  (hat  the  current  sums  relumed  by  Get_Integrals  are  correct,  verify  that  the  package  sends  correct 
measurements  to  Kalman_Filter  at  the  correct  times,  and  verify  that  a  measurement  is  not  sent  if  it  has 
been  cancelled.  The  test  designer  would  use  the  requirements  specification  and  the  Ada  package 
specification  to  develop  the  tests. 
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The  white  box  lest  designer  would  also  use  the  package  and  procedure  body  listings  to 
generate  test  cases  that  cover  all  the  paths  and  exercise  all  the  branch  conditions.  For  example,  the  white 
box  test  of  procedure  Cancel_Measurement  (see  Figure  8)  would  call  this  procedure  twice,  once  with 
measurement_pcnding  true  and  once  with  it  false.  (Measurement_Pending  is  stored  in  the  package  body.) 


with  Environment ; 
itparat*  |UljimantJtaM\ira«anta) 
procedure  Cenael_Meeaurement  la 
begin 

If  Meaau remen t_Pending  then 

—  — aend  invalid  meaauramant  to  the  Kalman 

Environment  .Heeauraaaenta  ■  lere_ia_Xllgnment_Meeauraa»ent 
(Tima_of_Alignm_Data  ■>  Neaaurament_Ilme, 


Alignm_Valld 

*> 

FALSI 

HmiX 

•> 

0.0, 

KuiT 

*> 

0.0, 

MaaaK 

-> 

0.0, 

VarX 

■> 

0.0, 

VarY 

■> 

0.0, 

Var« 

■> 

0.0); 

—  — cancel  meaaurament  pending  flag 

Meaaurament_Eendlng  :•  FALSE; 

and  if; 

end  Canael_Kaaauramant; 


Figure  8.  Procedure  CanceLMeasurement 


The  Alignment_Measurements  test  was  primarily  a  black  box  (i.e.,  functional)  test,  with 
some  additional  test  cases  to  cover  the  white  box  criteria. 


(2)  Process 

After  a  unit  had  been  walked  through  and  approved,  the  unit’s  designer  wrote  the  test 
procedure.  Procedures  were  written  in  DoD-STD-2167  format,  and  each  one  was  reviewed  by  the  entire 
1 1th  Missile  team.  An  engineer  other  titan  the  unit's  designer  wrote  the  test  driver  code  ad  executed  the 
test. 


Most  unit  and  package  tests  were  first  executed  on  the  VAX  using  the  DEC  Ada  compiler 
(see  Figure  9).  This  approach  was  originally  adopted  because  of  the  problems  encountered  with  the  early 
Ada/1750A  cross-compilers.  There  was  an  unexpected  productivity  benefit,  however,  because  DEC’S 
program  debugging  and  library  management  tools  were  much  better  than  those  provided  by  the  1750A 
cross-compiler.  Errors  could  be  found  and  corrected  much  faster  with  DEC’S  tools  than  with  the  cross- 
compiler's  tools.  These  units  were  then  tested  on  a  1750A  simulator  or  1750A  hardware.  Since  the  code 
and  the  test  drivers  had  been  checked  out,  these  tests  were  primarily  to  debug  the  1750A  cross-compiler, 
time  the  software,  and  check  numerical  accuracy. 
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Some  units  (e.g.,  the  1553B  bus  interface)  could  not  be  meaningfully  tested  unless  they 
were  compiled  by  a  1750A-targeted  compiler,  and  so  were  first  tested  on  the  1750A  Simulator. 


Figure  9.  Test  Approach 

e.  Integration  and  Hardware-in-the-Loop  Tests 

The  Laser  Guidance  group  of  McDonnell  Douglas  Astronautics  Company  developed  the 
simulation  facility  used  by  the  11th  Missile  Application;  the  11th  Missile  Application  software  was 
developed  to  be  consistent  with  the  requirements  of  this  facility.  The  hardware  configurations  used  in 
integration  and  hardware-in-lhe-loop  tests  are  shown  in  Figure  10.  The  baseline  simulation  setup, 
Operator  Control  Unit  (OCU)  and  flight  Digital  Processing  Subsystem  (DPSS),  utilized  two  1750A 
processors.  Because  only  one  1750A  processor  was  available,  the  alternate  breadboard/monitor  con¬ 
figuration  was  used.  With  this  alternate  configuration,  the  11th  Missile  Application  software  required 
minor  modifications.  The  Guidance  computer  was  converted  from  a  remote  terminal  (RT)  to  a  bus 
controller  (BC). 

The  hardware-in-the-loop  tests  for  the  Guidance  CSC  were  successfully  completed,  but  the 
Navigation  CSC  hardware-in-the-loop  testing  could  not  be  performed  given  the  inability  of  the 
Ada/1750A  cross-compiler  to  generate  correct  Ada  code  for  this  portion  of  the  application  and  the  un¬ 
availability  of  work-arounds.  The  tests  uncovered  six  errors  in  the  1 1th  Missile  Application  software  and 
three  errors  in  the  Ada/1750A  compiler  code.  The  Guidance  CSC  required  87.2%  of  the  throughput.  A 
more  detailed  description  of  the  results  may  be  found  in  the  Software  Test  Report  (Reference  1). 

The  I  Ith  Missile  Application  testing  demonstrated  that  given  efficient  and  effective  Ada  com- 
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OCU  and  FHght  DPSS  BraadboarcMWonllor 

Figure  10.  Hardware  Configurations 

pilers,  the  CAMP  parts  may  be  used  in  embedded  real-time  software.  The  CAMP  parts  were  functionally 
correct,  but,  with  the  current  Ada/1750A  compilers,  most  generics  had  to  be  manually  instantiated  (see 
Section  VI). 

The  1 1th  Missile  Application  CSCI  is  not  effective  flight  software  due  to  long  execution  time. 
The  Guidance  CSC  runs  three  times  slower  than  a  nearly  equivalent  JOVIAL  version  of  the  same  applica¬ 
tion.  The  Navigation  CSC  would  not  have  been  able  to  run  in  real  time.  The  main  sources  of  in¬ 
efficiencies  were  Ada  task  rendezvous  and  the  compiler’s  implementation  of  generics;  Section  VI  dis¬ 
cusses  the  Ada  issues  in  more  detail. 

f.  Tools 

Table  4  lists  the  tools  used  by  the  1 1th  Missile  team  and  the  software  development  phases  in 
which  they  were  used. 
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TABLE  4.  TOOLS  USED  BY  SOFTWARE  DEVELOPMENT  PHASE 


Tool 

Top 

Level 

Design 

Detailed 

Design 

Unit 

Test 

Integration 

Test 

Requirement*  Map* 

X 

Message  Map* 

X 

X 

Decomposition  Diagram* 

X 

Structure  Charts 

X 

Digital  Standard  Runoff 

X 

X 

Comment  Extractor 

X 

DEC  Ada  Compilation  System 

X 

X 

X 

TLD  VAX/I750A  Ada  Compiler  System 

X 

Compiler  Conversion  Utilities 

X 

mm 

MDAC-HB  I750A  Simulator 

X 

MDCROS  1750 A  Emulator 

X 

Hardware -In -The -Loop  Simulation 

X 

DEC  Code  Management  System 

X 

mm 

Software  Development  Files  < 

X 

X 

Development  Status  Database 

X 

X 

Smart  Code  Counter 

X 

X 

(1)  Requirements  Mapping  Tools 

Requirements  maps  were  used  to  verify  the  completeness  of  the  design.  These  maps  (see 
Table  5  for  an  example)  correlated  the  software  implementation  and  the  requirements;  they  were  used  to 
verify  that  all  requirements  were  implemented.  The  maps  also  appeared  in  the  TLDD.  The  message 
maps  (see  Table  6  for  an  example)  showed  which  element  (subprogram  or  task)  processed  each  1553B 
bus  message,  and  served  to  verify  that  the  software  processed  every  bus  message. 

(2)  Design  Visualization  Tools 

Decomposition  diagrams  and  structure  charts  were  used  to  provide  two  different  views  of 
the  software  design.  The  decomposition  diagram  clearly  showed  the  functional  partitions  of  the  software; 
the  structure  charts  showed  the  packaging  structure  of  the  Ada  code. 

The  two  visual  aids  are  consistent,  except  for  the  data  type  definition  packages.  For  ex¬ 
ample,  package  Kalman_Types  is  logically  a  part  of  the  Kalman  Filter  function,  and  is  therefore  shown 
below  package  Kalman_Filter  in  the  decomposition  diagram  (see  Figure  6,  at  the  far  right  edge). 
However,  this  would  have  forced  the  Kalman_Filter  and  Environment  packages  to  "with"  each  other, 
which  would  violate  an  Ada  language  rule.  Therefore,  package  Kalman_Types  is  separate  from  Kalman, 
Filter  and  appears  as  such  in  its  structure  chart  (see  Figure  3). 
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TABLE  5.  NAVIGATION  TLCSC  FUNCTIONAL  ALLOCATION 

TO  LOWER  LEVEL  COMPUTER  SOFTWARE  COMPONENTS 

(Pari  1  of  2) 
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*1  Satisfies  those  puts  of  the  puagraph  that  apply  to  the  larigatios  Counter 
*2  This  is  the  primary  CSC  to  meet  the  requirements  of  this  section. 

*3  This  is  a  secondary  CSC;  it  supports  the  primary  CSC  in  aeeting  the  requi meets  of  this  section. 


TABLE  5.  NAVIGATION  TLCSC  FUNCTIONAL  ALLOCATION 
TO  LOWER  LEVEL  COMPUTER  SOFTWARE  COMPONENTS 


(Concluded) 
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*1  Satisfies  those  parts  of  tha  paragraph  that  apply  to  the  Irrigation  Counter 
*2  This  is  the  priaary  CSC  to  aaet  the  requirements  of  this  section. 

*3  This  is  a  secondary  CSC;  it  supports  the  priaary  CSC  in  aaetiag  the  requireaeats  of  this  section 


TABLE  6.  NAV  COMPUTER  MESSAGE  MAP 
(Part  1  of  2) 


Maaaaga  ZD 

Mag  Symbol 

ZPSS-NAV  -  40 

KOLTO 

ZPSS-MAV  -  41 

N0NTPF2D 

ZPSS-NAV  -  42 

KDNTPF3D 

IP  SB -NAV  -  43 

K0PTB 

ZPSS-NAV  -  45 

TPMOPD 

ZPSS-NAV  -  50 

LFUTZME 

ZPSS-NAV  -  51 

NTPF2DTZME 

ZPSS-NAV  -  52 

NTPF3DTZME 

ZPSS-NAV  -  53 

PTBTZME 

ZPSS-NAV  -  54 

TPMTIME 

ZSA  -SAD  -132 

APDATA 

ZSA  -BAD  -133 

cio cr 

ZSA  -NAV  -  S 

INCHA. 

ZSA  -NAV  -  » 

DTNAM 

ZSA  -NAV  -  10 

ZSSTAT 

NAV  -BAD  -130 

NAVDAT 

NAV  -BAD  -131 

NAVPOSCCV 

NAV  -EXEC-  1 

ATTITEXEC 

NAV  -GOID-  1 

ATTITOOXD 

NAV  -OUZO-  2 

ATTIT00ID2 

NAV  -ZSA  -  3 

INITAT 

NAV  -ZSA  -  4 

FKINC 

NAV  -ZSA  -  5 

KALCOA 

NAV  -ZSA  -  6 

ISACMD 

NAV  -OCO  -  4 

NAVSTAT 

NAV  -OCO  -  C 

RTBIMERR 

NAV  -SCP  -  2 

ALP  BA 

NAV  -SCP  -  3 

CORRECT 

NAV  -TUI  -  7 

KALRLT2 

NAV  -TLM  -  13 

KF_DIA0 

NAV  -TIH  -  15 

RALSAN 

NAV  -TIM  -  16 

VAR 

NAV  -TIM  -  17 

PHIDIACN0S 

NAV  -TIM  -  18 

KALRLT1 

NAV  -TIM  -  19 

KALSTER 

Kmlauui_rilt«r .  Itqunetr  .MumaMnt_lr*prooMiin( 
ICalaan_Flltag .  Stquuoar .  Huiutiniit_Prafro«ufin} 
Kalman_Flltar .  Saquanoag .  Maaaur*aMnt_Pgaprooaaalng 
Ealman_riltar .  Saquanoag  ■  Haaaug«m«nt_Prapgooaaalng 
KalmanJFlltag .  laquancar .  Maaaur— *nt_Praprooa*alng 
Kalnan_Flltag .  Saquanoag .  Maaaur***ant_t  raprooaaalng 
Kalaan_Flltar .  Saquanoag  .  Maaaug*mant_Pgaprocaaaing 
Kalman_Flltag. Saquanoag  .Haaaug—ant_P  raprooaaalng 
Kal*an_Flltar.  Saquanoag.  Maaaugaa»nt_Praproaaaalng 
Kalman_Flltag.  Saquanoag.  HaaauraawntJPgapgooaa  a  Ing 
Mav_Sya torn .  Saquanaar 

Envlronmant  .Maaaaga_Managaaant  ,Maaaaga_Managag 
Nav_Syat*a .  Saquanaar 
Nav_Byataa. Saquanoag 

Environaant .  ISA.  ISA_Coaa_BXT_And_Nonitor 

Ntv  Jyataa .  S aquanoag  (via  Navlgatlon_Oparat  Iona  .  - 

Exaauta_Navlgator) 

Kalaan_Flltag .  f  aquanoag .  Updata_Managar .  - 
•and_Coggaotion_Maaaagaa 
Nav_8yat*a . Saquanaar 
navigation . Saquanoag 
Navigation . Saquanoag 
Nav_Syataai .  Moda_Cont  gollag 

Nav_Syataai .  Saquanoag  (via  NovlyationjOparatlona .  - 

Emaoutajfovlgatog) 

Kalaan_Flltag .  Saquanoag .  Opdata_Hanagag . Ralnlt ialiia 
(Initial  tilt  ooggaotlon  maaaaga) 

KalawnJTlltar .  Saquanoag .  Updata_Managar .  - 
Sand_Coggaatlon_Naaaagaa  (all  othaga) 

Environmant .  ISA .  ISA_Con»_BIT JkadJtonltog 
Nav_Syatam. Statua_Oanaratog 
Invlgonaant .  RT_*m_Eggog_Sandlag 
Nav_Syataai .  Saquanoag 

KalaanJFlltag .  Saquanoag .  OpdataJKanagar .  - 
Sand_CoggaatlonJMaaaagaa 
Kalaan_Flltag .  Saquanoag .  OpdataJManagar .  - 
Sand_Coggaot 1 on JHaa  a  agaa 
Kalaan_Flltag .  Saquanoag .  OpdataJManagar .  - 
Sand_CoggaotlonJMaaaagaa  (F  and  X  tarma ) 
Kalnan_Flltag.Saquanear.Phl_9_Majiagag  (phi  4  Q  tarma ) 
Kalman_Flltag .  Saquanoag .  Opdata_Managar .  - 
Opdata_And_Sand_Maaaagaa 
KaLaan_Flltar .  Saquanoag .  Opdata_Hanagar .  - 
Ratriava_And_Propagata  (P  prop*) 

Kalman_Flltag .  Saquanaar .  Opdata_Managar .  - 
Opdata_And_Sand_Haaaagaa  (P  updataa) 

Kalman_Filtar. Saquanoag. Phl_Q_Hanagag  (phi  pgopa) 
Kalman_Filtar .  Saquanoag .  Opdata_Managar .  - 
Ratrlava_And_Propagata  (PCX  propa) 

Kalman_F lltag .  Saquancar .  Opdata_Hanagar .  - 
Sand_Co grae  1 1 on_Maa  a  agaa 
Kalman_Flltar .  Saquanaar .  Updata_Managag .  - 
Ratrlava_And_Propagata  (X  propa) 

KalmanJTlltag.  Saquanoag.  Opdata_Managar .  - 
Opdata_And_Sand_Maaaagaa  (X  updataa) 

Kalman_Flltar .  Saquanaar .  Updata_Managar .  - 
Sand_Corraction_Ha»aaga»  ( ouan  arrora) 
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TABLE  6.  NAV  COMPUTER  MESSAGE  MAP 


(Concluded) 


Maaaaga  ID 

Mag  Symbol 

WAV  -TIM 

- 

21 

QDIASN03T 

NAV  -TLM 

_ 

23 

FDTDIAGNOS 

NAV  -TLM 

26 

XTMKAS 

NAV  -TIM 

_ 

28 

rSUMDIAG 

NAV  -TIM 

“ 

33 

KALPER 

OCU  -NAV 

2 

NAVCMD 

OCO  -NAV 

- 

82 

PREPJWNLD 

OCU  -NAV 

- 

84 

3TART_APPL 

OCU  -NAV 

- 

86 

IMTOBDALN 

OCU  -NAV 

- 

87 

IWDGNDALN 

OCO  -NAV 

- 

92 

NXWLEVARM 

SCF  -NAV 

- 

39 

DOP  TIME 

8 CP  -NAV 

- 

40 

DOPUPD 

TPM  -NAV 

- 

4S 

TFMUFD 

Bandied  By 


Kalakan_rlltar . Sequencer . Phi_Q_Man»g*r  (Q  props) 
Xalaui_riltei .  Sequencer .  <7pdate_Kanaqer .  - 
Retrleve_And_Propaqate  (I  propa) 

Kalau_rilter .  Sequencer .  Phl_Q_Man»g«r 
Kalaen_Filter .  Sequencer .  Opdate_Henager .  - 
Opdete_And_Send_Measegea 

Kalman_rl  Iter .  Sequencer .  Phl_Q_Man»g«r  (phi  S  Q  props ) 
Ka le*n_r liter .  Sequencer .  Updata_Manag*r .  - 
Opdste_And_Send_Messaqes  rla 
Kelmen_r  liter .  &llynamnt_Dlseretes .  Put_P 
Nar_Systea.Hode_Cont roller 

Envlronawnt  .Mesaeqe_Meneger  Tie  Systeaa_Controller 
EnrlronaMnt  .Mesaeqe_Menaqer  vie  tyatcei^Cont roller 
MavSysteei .  Mode_Con  t  roller 
Mer_8yataai .  Mode_Cont  roller 
Nar_8yataa .  Mode_Cont  roller 

Kalaen_rilter .  Sequencer .  MeesureaMnt_P  reprocessing 
Kelaen_rilter .  Sequencer .  Measuraa>ent_P  reprocessing 
Kal  een_rilter .  Sequencer .  MeesuresMnt_P  reprocessing 


(3)  Documentation  Tools 

The  1 1th  Missile  team  used  Digital  Standard  Runoff  (DSR)  to  format  the  top-level  design 
document  (TLDD)  and  the  test  procedures  document.  The  bulk  of  the  TLDD  was  extracted  from  the  code 
headers  and  formatted  for  DSR  by  the  Top-Level  Design  Comment  Extractor  (see  Volume  I,  section 
11.2.e(4)),  a  tool  developed  by  MDAC-STL. 

(4)  Ada  Compilers 

The  1 1th  Missile  team  had  access  to  two  different  VAX/1 750A  cross-compilers;  these  will 
be  referred  to  as  "Compiler  A"  and  "Compiler  B".  This  is  partly  to  protect  the  compiler  vendors’ 
proprietary  information,  and  partly  because  the  information  presented  here  will  (hopefully)  soon  be  out- 
of-date  as  improvements  are  made  to  the  compilers. 

Neither  compiler  handled  generics  well  enough  to  use  the  CAMP  parts  without  modifica¬ 
tion  (see  Volume  I,  section  VI).  For  this  reason,  and  because  DEC’S  Ada  Compilation  System  (ACS) 
provides  far  better  library  management  and  code  debugging  tools,  the  11th  Missile  team  used  the  DEC 
Ada  compiler  extensively.  The  DEC  compiler  was  the  only  one  used  during  the  design  phases,  and  was 
used  with  a  1750A  cross-compiler  during  unit  testing  (see  Section  II.2.d).  In  the  top-level  design  phase,  it 
was  particularly  useful  when  designing  the  task  bodies,  since  the  compiler  automatically  checked  task 
accept  statements  and  subprogram  calls  for  consistency  with  the  task  entry  and  subprogram  definitions, 
respectively.  In  both  design  phases,  code  had  to  compile  before  it  was  walked  through.  "Compiler  B" 
was  used  for  the  1750A  version  of  the  unit  tests  and  for  the  integration  tests. 
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Using  three  Ada  compilers  meant  developing  three  versions  of  some  of  the  code.  The 
compiler-specific  code  consisted  primarily  of  pragmas  and  representation  specifications.  The  11th  Mis¬ 
sile  team  did  this  by  writing  all  three  versions  in  one  file  and  commenting  out  the  lines  that  did  not  apply 
to  the  DEC  compiler.  Utility  programs  converted  the  files  for  use  by  another  compiler  by  commenting 
out  the  DEC-specific  statements  and  activating  the  statements  for  the  specified  compiler  (see  Figure  1 1 ). 

(5)  Test  Tools 

Most  unit  tests  were  executed  on  the  MDAC-HB  1750A  Simulator,  a  FORTRAN  program 
that  simulates  the  operation  of  a  1750A  chip.  Using  this  program,  the  1 1th  Missile  team  was  able  to  run 
(hose  unit  tests  that  did  not  use  an  external  interface  (i.e.,  the  1S53B  bus  or  the  barometric  altimeter  port). 

The  simulator  is  quite  slow,  so  some  computation-intensive  unit  tests  were  executed  on  the 
MUCROS  1750A  Emulator  or  on  a  1750A  breadboard  from  the  original  1 1th  Missile  project.  The  MIK- 
ROS  is  a  SEAFAC-certified  1750A  implementation  that  is  designed  to  be  a  co-processor  with  an  IBM 
PC/AT.  Programs  were  downloaded  from  the  IBM  PC  to  the  1750A  target  and  executed  on  the  1750A 
hardware.  The  breadboard  is  built  around  an  MDC281  implementation  of  the  1730A  architecture  and 
contains  128K  of  memory.  For  unit  tests,  software  was  downloaded  and  controlled  from  a  VAX  1 1/780 
via  a  1750A  Monitor. 

The  integration  tests  were  executed  on  the  hardware -in-the-loop  simulation  (see  Section 

II.2.e). 


(6)  Ollier  Software  Development  Tools 

Two  other  tools  used  curing  software  development  were  Software  Development 
Notebooks  (SDNs)  and  the  DEC  Code  Management  System  (CMS). 

Generally,  there  was  an  SDN  for  each  high-level  package,  but  if  it  was  large  (e.g., 
Environment),  there  could  be  separate  SDNs  for  its  sub-packages.  There  were  approximately  forty  11th 
Missile  SDN’s.  A  module’s  Software  Development  Notebook  (SDN)  contained  the  following: 

•  The  SRS  pages  that  applied  to  the  module 

•  The  Ada  code 

•  The  test  plan  pages  that  applied  to  the  module 

•  The  test  driver’s  code 

•  The  test  results 

CMS  is  a  configuration  management  tool,  which  served  as  the  central  source  code  library 
for  the  1 1th  Missile  and  kept  track  of  code  modifications.  Only  one  person  could  reserve  a  file  from  CMS 
at  a  time,  thus  ensuring  that  one  person’s  revisions  could  not  be  lost  due  to  a  file  being  overwritten  by 
another  person.  CMS  is  integrated  with  the  Ada  compilation  system  (ACS)  to  the  extent  there  is  an  ACS 
command  to  recompile  all  "out  of  date"  modules  (object  code  older  than  the  corresponding  source  code  in 
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****  DEC  Version  ♦*** 


foe  lnltat_maaaagaa  uaa 
record 


word_eount 

at 

0*RP .  atoraga_unlta_par_word 

rang* 

0.  .13 

aourca 

at 

1*RP . atoraga_unlta  _par_word 

rang* 

0.  .  3 

daatinatlon 

at 

1*RP . atoraga  unlta  par  word 

rang* 

4..  7 

maaaaga_numbar 

at 

1*RP .  atornga_unita_par_word 

rang# 

«.  .13 

affactlva_tina 

at 

2*RP .  atoraga_unita_par_word 

rang# 

0.  .31 

—  "B" 

init_quat_0 

at 

4*RP . atoraga_unita_par_word 

rang* 

0.  .13 

--HA" 

lnlt_quat_0 

at 

4*RP .  atoragn_unita_par_word 

rang* 

0.  .13 

—  "A" 

inlt_quat_l 

at 

3*RP . atoraga  unlta_par  word 

rang# 

0.  .13 

—  "B" 

init_quat_l 

at 

5*BV .  atoraga_unita_par_word 

rang* 

0.  .13 

and  raoord; 


for  initat_maaaagaa'  ait*  uaa  BI .  maaaaga_aiia;  — VXX 

—  "B"  for  inltat_maaaagaa' alaa  uaa  BZ . raaaaaga_aiza+32; 

—  “A"  for  initat_maaaagaa‘  alaa  uaa  BI  .maaaaga_aiza; 


****  -B"  Version  ♦*** 


for  lnitat_maaaagaa  uaa 
raaord 


word  count 

at 

0*FP .  atoraga_unlta_j>ar_word  ranga 

0. .13; 

aouroa 

at 

1*M .  atoraga_unitn_par__word  ranga 

0..  3; 

daatinatlon 

at 

1*U .  atoraga_unlta_par_word  ranga 

4..  7; 

at 

1*M. a toraga_uni t a_par_word  ranga 

B. .13; 

af  faotiva__tlaa 

at 

2*W.atornga_unlta__par_word  ranga 

0. .31; 

lnlt_quat_0 

at 

4 *n .  a toraga_unlt »_par_word  ranga 

0..13;  — -B" 

--"A" 

lnlt_quat_0 

at 

4*M .  atoraga_unlta_par_word  ranga 

0. .13; 

—  "A" 

lnlt_quat_l 

at 

3*RP .  atoraga_unlta_par_word  ranga 

0. .13; 

inlt_quatl 

at 

!*B .  atoraga_unlta_par_word  ranga 

0..13;  — -8" 

and  raaord; 


— VAX  for  lnltat_maaaagau'  alaa  uaa  BI  .maaaaga_alza; 

for  lnitat_maaaagaa' alaa  uaa  BI  .■aazaga_alaa+32;  — "B" 
-'"A"  for  lnitat_maaaagaa'  alaa  uaa  BI  .maaaaga_aiaa; 


****  "A”  Version  **** 


for  inltat_maaaagaa 

Ul« 

record 

word_oount 

at 

0*RP .  atoraga_unlte_par_word 

ranga 

0. 

.13 

•ourct 

at 

1*W.  atoraga  unlta  par  word 

ranga 

0. 

.  3 

daatinatlon 

at 

1*RP .  etoraga_unita_par  word 

ranga 

4. 

.  7 

naaaaga_numbar  at 

1*RP . atoraga_unita_par  word 

ranga 

a. 

.13 

•f factiva__tiraa  at 

2*RP .  atoraga  unitcj>«r  word 

ranga 

0. 

.31 

—  "B" 

lnlt  quat  0 

at 

4*RP. atoraga  unlta  par  word 

ranga 

0. 

.13 

initquatO 

at 

4*RP. atoraga  unlta  par  word 

ranga 

0. 

.13 

—  "A" 

lnlt  quat  1 

at 

3*RP  .  atoraga  unlta  par  word 

ranga 

0. 

.13 

—  "A" 

--"B" 

init  quat  1 

at 

5*R2 . atoraga  unlta  par  word 

ranga 

0. 

.13 

•nd  raaord; 

--VAX 

for  lnltat  maaaagaa' alaa 

uaa  BI .  maaaaga_aixa; 

--"B" 

for  lnltat  maaaagaa 

a  1  ce 

uaa  Bl.maaaaga  alzo+32; 

for  lnitat_raaaaagaa 

alaa 

uaa  BI . maaaaga_uiza;  --"A” 

Figure  11.  Code  for  Three  Compilers  Combined  in  One  File 
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CMS).  CMS  was  also  used  for  configuration  control  of  the  Top-Level  Design  Document,  the  Test  Plan, 
the  Test  Procedure,  and  the  Final  Technical  Report. 


(7)  Management  Toots 

A  development  status  database,  implemented  using  ORACLE  (a  commercially  available 
relational  database),  helped  track  the  status  and  size  of  the  1 1  th  Missile  software.  Each  developer  was 
responsible  for  updating  the  database  as  appropriate.  A  program  automatically  generated  a  weekly  status 
report  and  sent  it  to  all  the  developers  and  management. 

The  "smart"  code  counter  (see  Volume  I,  section  I1.2.e(5))  was  used  to  count  the  individual 
modules  for  the  software  size  fields  of  the  database.  An  ORACLE  command  file  calculated  the  total 
software  size. 
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SECTION  III 


EVALUATION  OF  THE  CAMP  PARTS 
AND 

THEIR  USE  IN  THE  I1TH  MISSILE  APPLICATION 

Two  versions  of  the  1 1th  Missile  Application  were  designed  and  tested.  The  first  used  the  CAMP 
parts,  and  is  referred  to  as  the  "Parts  Method".  This  was  a  complete  implementation  of  the  11th  Missile 
requirements.  The  second  implementation  used  the  CAMP  parts  and  parts  composition  system  (PCS)  and 
is  covered  in  Section  IV;  it  is  referred  to  as  the  "PCS  Method". 

I.  PRODUCTIVITY 

During  the  lltb  Missile  Application  development,  effort  data  was  maintained  in  order  to  determine 
the  effect  of  CAMP  parts  and  PCS  usage  on  productivity.  In  analyzing  this  data,  one  very  important  issue 
was  highlighted;  Use  of  Ada  for  RTE  applications  requires  mature,  highly  optimized  compiler*  Al¬ 
though  great  strides  have  been  made  in  the  development  of  Ada  compilers  in  general  —  the  DEC  VAX 
compiler  is  a  good  example  of  this  —  Ada  cross-compilers  for  RTE  applications  are  not  yet  fully  mature. 
This  situation  is  similar  to  the  one  that  existed  several  years  ago  when  high-quality  Ada  compilers  for 
non-RTE  targets  were  hard  to  come  by.  This  is  characteristic  of  the  cyclic  development  of  technology  in 
general.  As  the  demand  and  need  for  higher  quality  and  greater  efficiency  in  Ada  cross-compilers  in¬ 
creases,  compiler  developers  will  find  increasing  incentive  to  expend  the  resources  needed  to  improve 
their  products  and  incorporate  the  features  (hat  the  11th  Missile  team  found  to  be  so  important  for 
developing  effective  RTE  applications. 

With  this  in  mind,  it  is  not  surprising  that  the  Uth  Missile  development  team  spent  a  significant 
amount  of  time  debugging  the  1750A  cross-compiler.  The  CAMP  data  indicates  that  with  a  mature 
compiler,  a  productivity  improvement  of  up  to  15%  was  possible  using  the  CAMP  parts.  This  figure  is 
based  on  the  adjusted  testing  hours  shown  in  Table  7.  Adjustments  were  based  on  two  factors. 

1.  There  was  a  disproportionately  large  test  effort  due  to  the  immaturity  of  the  Ada/1750A  compiler. 
Of  the  153  errors  discovered  during  testing,  96  were  compiler  errors  and  57  were  errors  in  the  1 1th 
Missile  code  or  the  CAMP  parts.  Based  on  this,  it  seems  reasonable  to  assume  that  half  the  test 
time  was  spent  debugging  the  compiler. 

2.  Again,  because  the  Ada/1750A  cross-compiler  could  not  generate  correct  Ada  code  for  portions  of 
the  Navigation  CSC,  and  because  adequate  work-arounds  for  the  problems  did  not  exist,  testing  of 
the  Navigation  CSC  was  not  completed  (see  Section  Vi).  At  the  end  of  the  project  it  was  es¬ 
timated  that  another  240  hours  would  be  required  to  fully  test  this  CSC  once  the  compiler 
generated  correct  code. 
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Therefore,  (he  adjusted  test  effort  estimate  is: 

Test_Effort  =  0.5  x  4779  hr  +  240  hr  =  2630  hr 

As  a  cross-check,  this  is  45%  of  the  adjusted  total  effort,  which  is  roughly  in  line  with  the  40%-design/ 
20%-code/40%-lest  rule  of  thumb. 

The  raw  data,  without  the  adjustment  for  compiler  immaturity  (i.e.,  if  all  of  the  time  spent  debugging 
the  compiler  is  carried  as  a  cost  of  using  the  parts),  would  actually  indicate  a  productivity  decrease  of 
18%.  One  of  the  most  obvious  areas  of  the  compiler's  immaturity  was  in  its  inability  to  handle  the 
complex,  though  perfectly  standard,  Ada  generics  used  extensively  in  the  CAMP  parts. 


TABLE  7.  11TH  MISSILE  EFFORT 


Effort 

(houra  ) 

Phaaa 

Actual 

Adjuatad 

Raquiraaianta 

708 

708 

Archltaotural  Daaign 

883 

883 

Dat.  Daaign  6  Coda 

1306 

1306 

Taatlng 

4779 

2630 

Othar 

371 

371 

Total 

8047 

5898 

Table  8  shows  the  size  of  the  1 1th  Missile  software  in  both  lines-of-code  (LOC)  and  Ada  statements. 
The  "generated"  code  comprises  two  sparse  matrix  operators  that  were  generated  using  portions  of 
preliminary  versions  of  the  CAMP  parts  composition  system  Kalman  Filler  Constructor.  Parts  statement 
counts  are  estimated  from  the  overall  ratio  of  statements  to  LOC  for  the  parts  (0.634  statements/LOC). 
The  "other  reused"  test  software  is  FORTRAN  and  Harris  assembler  code  used  for  the  hardware-in-the- 
loop  tests.  It  was  estimated  that  there  were  0.9  statements/LOC  for  this  software.  Table  9  shows  the 
actual  productivity. 


TABLE  8.  1 1TH  MISSILE  SIZE  -  PARTS  METHOD 


Llnaa 
of  Coda 

8tata- 

manta 

Oparational  Coda 

Maw 

13708 

8697 

Ganaratad 

1108 

471 

Mod.  Parta 

39' 

438 

Part  a 

3911 

2480* 

Total 

21624 

12106 

Taat  Softwara 

Haw 

19732 

12605 

Parta 

1114 

706* 

Othar  Rauaad 

14544 

13090* 

Total 

35410 

26401 

*  Eatimatad 

26 


TABLE  9.  UTH  MISSILE  PRODUCTIVITY  -  PARTS  METHOD 


Wew 

All 

Maw 

JU1 

Operational 

Oparational 

Developed 

Developed 

lOC/Work -Month 

304.5 

419.2 

687 . 4 

1105.7 

S tat /Work -Month 

ice.  5 

234.7 

413.0 

746.5 

Work-Bours/LOC 

0.51 

0.37 

0.23 

0.14 

Work-Bours/Stat 

0.93 

0 . 66 

0.38 

0.21 

CAMP  parts  constituted  18.1%  of  the  Parts  Method  implementation  of  the  lllh  Missile  code  and 
3.1%  of  the  test  code  (see  Table  8).  Using  the  adjusted  effort  as  a  basis,  the  11th  Missile  developers 
saved  896  work-hours,  15%  of  the  development  effort,  by  using  the  CAMP  parts.  Table  10  compares  the 
adjusted  effort  with  the  estimated  effort  required  had  the  parts  not  been  used. 


TABLE  10.  EFFECT  OF  PARTS  ON  1 1TH  MISSILE  EFFORT 


Effort 

(hours ) 

Adjusted 

Estimated 

With 

Without 

9haae 

Parta 

Parts 

Requirements 

708 

708 

Architectural  Design 

883 

883 

Det.  Dealgn  6  Code 

1306 

1604 

Testing 

2630 

3228 

Other 

371 

371 

Total 

5898 

6794 

Effort  Saved :  896  houra 

Productivity  Improvement : 

156 

The  increased  effort  that  would  have  been  required  for  tire  detailed  design  and  coding  phase  had  the 

parts  not  been  used  was  estimated  as  follows: 

__  _  DD_Effort-  DDjGen  Effort 

NewjCode  +  ModjCode 

_  1 306  hr  —  40  hr 

DD  Rate  = - 

15708  LOC  +  897  LOC 

DD  Rite  =  0.0762  Iv/LOC 

DDJSaved  =  DDJRate  x  PartsjCode 

DDJSavcd  =  0.0762  Itr/LOC  x  391 1  LOC 

DD_Saved  =  298  hr 

where  DD_Rate  =  Detail  design  and  code  productivity,  hours  per  line-of-code 
DD_Effort  =  Total  detail  design  and  code  effort,  hours 
DD_Gen_Effort  =  Estimated  effort  to  generate  code,  hours 
New_Code  =  New  operational  code,  lines-of-code 
Mod_Code  =  Modified  parts  code,  lines-of-code 
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Parts_Code  =  Parts  code,  lines-of-code 

DD_Saved  =  Detail  design  and  code  effort  saved,  hours 

This  estimate  is  conservative  because  il  assumes  that  it  look  as  long  to  code  the  modified  parts  as  it 
did  to  design  and  code  the  new  software. 


A  similar  calculation  for  the  increased  effort  that  would  have  been  required  to  test  without  the  parts 
yields: 


Test_Rate  = 
Test_Rate  = 


TestJEffort 

NewjCnde  +  Mod  JCode  +  Gen  JCode 
2630  hr 

15708  LOC  +  897  LOC  +  1108  LOC 


Test_Rate  =  0.148  lu/LOC 
Test_Saved_Op  =  Test_Rate  x  Parts jCode 
Test_Saved_Op  =  0.148  hr /LOC  x  391 1  LOC 
Test_Saved_Op  -  579  hr 

where  Tesl_Rate  =  Test  productivity,  hours  per  line-of-code 
Tesl_Effort  =  Total  test  effort,  hours 
Gen_Code  =  Generated  code,  lines-of-code 

TesL.Saved_Op  =  Test  effort  saved  due  to  parts  in  operational  code,  hours 


However,  part  of  the  test  code  was  itself  parts.  Adjust  for  this  as  follows: 

TestjCode 


Test_Saved  = 
Test_Saved  = 


New_Test JCode  +  Reused_Test_Code 
35410  LOC 


x  Test  _Saved_Op 


19752  LOC  +  14544  LOC 
Test_Saved  =  598  hr 


x  579  hr 


where  Test_Saved  =  Test  effort  saved,  hours 

New_Test_Code  =  New  test  code,  lines-of-code 
Reused_Test_Code  =  Reused  test  code,  lines-of-code 
Test_Code  =  Total  test  code,  lines-of-code 


New,  modified,  and  generated  code  are  included  in  the  testing  "rate  base"  because  all  of  this  code 
was  unit  tested;  the  parts  code  was  not.  There  is  a  small  error  in  this  calculation  because  part  of  (he  lest 
effort  was  devoted  to  debugging  parts.  The  magnitude  of  the  error  isn’t  known,  but  is  certainly  less  than 
100  hours. 


The  actual  development  effort  was  8047  hours.  It  may  be  argued  that  the  time  spent  debugging  the 
compiler  was  a  cost  of  using  the  parts: 

•  If  the  CAMP  parts  had  not  been  used,  complex  generics  would  not  have  been  used; 

•  If  complex  generics  had  not  been  used,  fewer  compiler  problems  would  have  been  encountered; 

•  If  fewer  compiler  problems  had  been  encountered,  total  effort  would  have  declined. 

It  is  difficult  to  assess  just  how  much  additional  lest  time  was  due  to  compiler  problems,  and  how  much 
of  that  additional  time  would  not  have  been  required  if  the  parts  were  not  used.  If  all  of  the  estimated 
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compiler  test  time  is  charged  as  a  cost  of  using  the  parts,  then  there  as  an  18%  decrease  in  productivity, 
computed  as  follows: 


Productivity -Improvement  = 


Estimated_Effort_Without_Parts 

Actual_Effort_With_Parts 


-  1.0 


Productivity -Improvement  =  -  1 .0 

Productivity -Improvement  =  -  0.1 8 

It  is  clear  that  an  immature  compiler  will  negate  the  benefit  of  using  the  CAMP  parts  "as  is". 


The  above  discussion  does  not  address  the  other  costs  of  using  parts.  For  example,  some  cost  is 
incurred  in  the  requirements  and  design  phases  since  the  software  designers  must  identify  the  parts  that 
may  be  used.  Data  was  not  kept  on  these  costs  during  the  11th  Missile  Application  development  since  the 
1  llh  Missile  developers  were  somewhat  familiar  with  the  parts  and  were  in  close  proximity  to  the  parts 
development  group.  Some  researchers  have  postulated  the  cost  of  reusing  parts  to  be  in  the  range  of  4% 
to  10%. 


2.  PARTS:  WHERE  THEY  WERE  USED 

CAMP  parts  comprised  about  one-fifth  of  the  flight  software  (see  Table  8).  However,  the  percentage 
of  parts  varied  widely  between  the  LLCSCs  (see  Figures  12  and  13).  These  figures  clearly  show  that  the 
interface  to  the  "outside  world"  is  a  major  area  for  which  there  are  few  CAMP  parts.  The  Message. 
Processing  and  Intcrnal_Bus  LLCSCs  of  both  processors  are  large  and  composed  almost  entirely  of  new 
code.  Message.Processing  converts  data  to  or  from  a  format  compatible  with  a  MJL-STD-1553B  bus. 
Intemal_Bus  controls  the  hardware  interface  to  the  bus. 
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LLCSC 


Parte  New 


Environment  LLCSC 


Bare_AMmeler 

10 

52 

ocu 

0 

133 

TIM 

128 

408 

ISA 

0 

254 

SCP 

0 

42 

ee 

0 

78 

Maaauromanli 

0 

lie 

Internal JJut 

0 

781 

Syalam_Clock 

56 

0 

LocalClock 

56 

0 

CPU 

0 

38 

MeeeagaProc 

136 

4053 

Mem.Manager 

124 

52 

Navigation  LLCSC 
NavSyetem  0 

503 

Oualarnloni 

50 

181 

Nav  Opa 

1727 

2500 

A«gn_Maaa 

0 

213 

Kalman_Flller  1522  4714 


0  1000  2000  3000  4000  5000  6000 


Llnaa  of  Coda 


Figure  12.  NAV  Computer  Parts  Usage 


LLC9C 

Part* 

N## 

Internal  But 

0 

740 

Metea8e_Proe 

141 

975 

MaaterTlme 

56 

0 

CPU 

0 

38 

Qutd.Opa 

1298 

1730 

Syttein  Op  Data  0 

34 

Gutd  Computer 

0 

49 

Mam_Manaoer 

52 

124 

Lla*c  of  Cod* 


Figure  13.  GU1D  Computer  Parts  Usage 
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The  applicable  parts  were  primarily  designed  for  navigation,  guidance,  and  Kalman  filtering.  The 
figures  show  that  most  of  the  parts  code  is  indeed  concentrated  in  the  Navigation_Operations,  Kalman. 
Filter,  and  Guidance.Operations  LLCSCs;  however,  parts  comprise  less  than  half  of  each  of  these 
LLCSCs.  New  code  in  these  three  LLCSCs  was  needed  primarily  to  provide  type  definitions  and 
operators,  sequence  calls  to  basic  functions,  and  perform  functions  for  which  parts  are  not  available  or  in 
a  manner  different  from  the  available  parts.  New  (non-parts)  Navigation.Operations  code  was  developed 
to  perform  the  following  functions: 

•  Define  types  and  operators  between  them.  Most  of  the  operators  are  scalar  multipliers  and  dividers 
(e.g.,  lcet  /  sec  =>  feet  per  second).  This  code  is  a  modification  of  the  Basic_Data_Types  part,  but 
since  most  of  it  was  written  by  the  1 1th  Missile  team,  it  is  counted  as  new  code. 

•  Sequence  calls  to  the  navigation  functions.  The  parts  provide  basic  navigation  operations  (e.g., 
compute  Coriolis  acceleration,  update  velocity),  but  do  not  provide  a  higher  level  procedure  to  call 
them. 

•  Compute  a  bias  altitude  for  the  barometric  altimeter 

•  Incorporate  Kalman  corrections 

•  Implement  a  third-order  barometric -altimeter  filter 

•  Multiply  two  coordinate-transform  matrices  and  transpose  the  result 
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The  new  Kalman_Filter  code  was  developed  to  perform  Che  following  functions: 

•  Define  types  and  operators  between  them.  Most  of  the  operators  are  sparse-matrix  operators,  some 
of  which  are  quite  large. 

•  Sequence  calls  to  the  Kalman  filter  functions.  The  CAMP  KaIman_Update  part  did  not  meet  lllh 
Missile  requirement  to  handle  more  than  one  type  of  measurement. 

•  Initialize  and  integrate  the  system  description  (F)  matrix. 

•  Initialize  the  covariance  (P)  matrix. 

•  Define  the  system  noise  (Q*)  matrix. 

•  Perform  measurement  reasonableness  tests. 

•  Compute  measurement  sensitivity  (H)  matrices. 

•  Compute  Kalman  corrections  for  the  navigator  and  for  other  subsystems  of  the  11th  Missile,  and 
maintain  a  running  sum  of  the  corrections. 

•  Compute  whether  or  not  an  alignment  maneuver  is  needed,  and  whether  or  not  the  navigator  is 
aligned. 

•  Provide  interfaces  to  other  subsystems. 

The  new  Guidance_Operations  code  performed  the  following  functions: 

•  Define  types  and  operators  between  them.  As  with  Navigation_Operations,  most  of  the  operators 
are  scalar  multipliers  and  dividers.  This  code  is  another  rewrite  of  Basic_Data_Types. 

•  Sequence  calls  to  the  guidance  functions.  Once  again,  the  parts  provided  the  basic  operations,  but 
did  not  provide  a  sequencing  procedure. 

•  Implement  a  modified  first-order  filter.  The  modification  allows  the  user  to  specify  the  initial  "past 
values"  stored  in  the  filter. 

•  Implement  a  lateral-directional  "autopilot"  that  drives  a  pilot’s  display  instead  of  rudder  and 
ailerons. 
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3.  PARTS:  USED,  MODIFIED,  UNUSED,  AND  WHY 


By  the  end  of  testing,  the  1 1th  Missile  software  existed  in  two  versions:  one  considered  the  baseline 
and  the  other  a  work-around  necessitated  by  compiler  problems  (see  Section  VI).  The  "baseline"  version 
was  the  software  as  it  was  designed  and  implemented,  assuming  a  trouble-free  compiler.  The  second  or 
"tested"  version  was  the  baseline  version  after  making  the  many  modifications  required  to  work  around 
compiler  problems. 

The  tested  version  did  not  differ  functionally  from  the  baseline  version.  However,  many  times,  a 
compiler  deficiency  forced  the  11th  Missile  team  to  search  for  alternate  means  of  accomplishing  a  given 
function.  This  allowed  testing  to  proceed  despite  compiler  problems. 

The  following  sections  explain  the  CAMP  parts  usage  in  both  the  baseline  and  tested  versions  of  the 
1 1th  Missile  Application, 

a.  Baseline  Version 

The  1 1th  Missile  baseline  flight  software  used  112  of  the  453  parts  (24.7%);  96  directly  and  16 
with  modification  (see  Table  11).  A  complete  list  of  (he  parts  and  how  they  were  used  is  included  in 
Appendix  A.  Most  of  the  CAMP  parts  were  used  in  three  LLCSCs:  Navigation_Operations,  Guidance. 
Operations,  and  Kalman_Filter  (see  Table  12).  The  following  data  pertains  to  the  use  of  CAMP  parts  in 
the  baseline  code. 

TABLE  11.  SUMMARY  OF  CAMP  PARTS  USAGE  -  PARTS  METHOD 


Part* 

Oaad 

96 

Parts 

Oaad  with  Modification 

16 

Part* 

Not  usad 

341 

433 

Oaad  24.7*  of  Part* 

0««d  23.1*  of  Part*  Llnaa-of-Coda 


(I)  Paris  Modified 

Table  13  lists  the  sixteen  parts  that  were  modified.  The  reasons  for  modifying  the  parts  are 
discussed  below. 

•  Basic_Data_Types:  Although  it  can  be  compiled,  it  is  not  intended  to  be  used  "as  is".  It  contains 
only  the  types  and  operators  needed  to  instantiate  the  navigation  parts  and  it  declares  all  floating¬ 
point  types  System. Max_Digits.  Any  application  will  need  to  define  additional  types  and  operators 
and  specify  the  actual  precision  desired  for  each  type.  The  1 1th  Missile  team  created  two  versions 
of  Basic_Da!a_Types,  one  for  Nav  (Nav_Compuler_Data_Types)  and  one  for  Guid  (Guidance. 
Dala.Types). 
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TABLE  12.  SUMMARY  OF  CAMP  PARTS  USED 


Part 


Khar*  Ditd 


Basic  Data  Types 

Abstract  Procassas 
Standard  Trig  and  Polynomials 

Coordinata  Vaotor  Matrix  Algabra 
and  Oanaral  Purposa  Math 
W0S72  Ellipsoid 

Coasaon  C  Wander-Asisiuth  Navigation 
Diraation  Cosina  Matrix  Oparationa 
Oanaral  Vaotor-Matrix  Algabra 

Kalman  nitar 
Abstract  Data  Structuras 

Quatamion_Oparations 
Waypoint  Staaring 

and  Gaomatrio  Oparationa 
Signal  Procasaing 
Cloak  Bandlar 

Onivarsal  Constants 


Conversion  r actors 
and  Unit  Conversions 
Bus  Interface 
External  Torn  Conversion 


Navigation_Operetiona 
Ouidanca_Oparations 
All  tasks 

Navigation_Opa rations 

Quidanoe_Operations 

Mavlgatlon_Oparations 

Gu  1  danoa_Oparat  ions 

Navlgation_Opa rations 

Ouldance_Operatlons 

Navigation_Oparatlons 

Navi gat lon_Opar at ions 

Kalman __Fi  Iter 

Mavlgatlon_Oparations 

Kalman_F  liter 

Hssw  ry_Managar  (WAG) 

Kalman_riltsr 

Quaternions 

Ouldanaa_Oparations 

Guidanoa_Oparatlona 
Systam_Tlaa  (KG) 
Looal_Tlma 

NavlgationjOparatlons 

Guldanoe_Operatlona 

Massage  Manager  (NSG) 
Massaga~Managar  (MSG) 

BXM_Xnterfaca  (N40) 
Barometric  Altimeter 


Number 

Used 


1 

22 

11 

3 

14 

14 

11 

■ 

3 

2 

• 

5 

1 


1 

_ 1 

112 


"Where  Used"  is  the  LLCSC  which  instantiates  or  laqports  the  part. 


TABLE  13.  CAMP  PARTS  MODIFIED 


Basic_Data_Types 

WOS72Jtllipaold_Metrlc_Data 

WGS72_Elllpsoid_Englneering_Data 

Standard_Trlg 

Sin 

Cos 

Sin_Cos 

Tan 

Arcs in 
Arcoos 

Arcs in_Arccos 
Arc tan 

Ganaral_Puzposa_Math 

Sguara_Root 

Signal_Procasslng 

rirst_Ordar_riltar 

Waypoint_Staaring 

Cross track_And_Heading_Error_Operatlons 
Bus_lntarfaca_Parts 
Abstract  Procassas 
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•  WGS72:  These  parts  import  Basic_Data_Types.  The  metric  part  was  changed  to  import  Guidance. 
Data.Types  and  the  engineering  (English)  part  was  changed  to  import  Nav_Computer_Data_ 
Types.  Constants  not  used  were  deleted. 

•  Standard.Trig:  This  is  another  example  of  a  part  not  meant  to  be  used  "as  is".  The  version  supplied 
with  the  CAMP  parts  invokes  the  VAX  Math  Library.  Any  non-VAX  application  will  have  to 
rewrite  the  entire  package  body  (except  for  function  Arctan2)  to  invoke  trigonometric  functions 
appropriate  for  that  application.  These  functions  will  normally  be  Polynomial  parts.  In  addition, 
most  applications  will  need  to  invoke  Reduction.Operations  to  map  the  input  to  the  domain  sup¬ 
ported  by  the  selected  polynomials.  Most  sine  polynomials,  for  example,  are  accurate  over  the 
domain  [-0.5pi  <=  x  <=  0.5pi],  If  the  input  is  outside  that  domain,  an  input  within  it  that  has  the 
same  sine  must  be  computed.  The  11th  Missile  Application  required  two  versions  of  Standard. 
Trig,  one  for  single-precision  floating-point  and  the  other  for  extended-precision  (see  Table  14). 

•  General.Purpose.Math:  The  Sqrl  function  invokes  the  VAX  Math  Library.  It  was  changed  to  use 
the  modified  Newton-Raphson  square-root  function  from  the  Polynomials  package. 

•  Signal.Processing:  First.Order.Filter  was  modified  so  that  the  initial  past  values  stored  in  the 
package  body  could  be  specified.  This  is  required  to  avoid  a  control  transient  when  the  autopilot  is 
initialized. 

•  Waypoint.Steering:  Crosslrack_And_Heading_Error_Operations  was  modified  to  use  two- 
parameter  arctangents  instead  of  single-parameters  ones.  This  was  required  to  avoid  floating-point 
overflow  when  heading  error  was  near  +90  degrees.  First.Order.Filter  and  Crosstrack.And. 
Heading_Error_Operations  are  the  only  parts  that  were  designed  to  be  used  "as  is"  that  had  to  be 
modified. 

•  Bus.Interface.Parts  and  Abstract.Processes:  These  are  schematic  parts,  i.e.,they  serve  as  a  guide  to 
the  implementor  (see  Volume  I,  Section  I.2.a). 

TABLE  14.  POLYNOMIAL  PARTS  USED  FOR  TRIGONOMETRIC  FUNCTIONS 


Polynomial 

function 

Singla-E raoiaion 

Ext andad-P raoiaion 

Sin* 

Bastings . 3in_R_4 term 

Haatinga . Sin.R.Starm 

Coaina 

Haatinga  Coa  R  4tarm 

Haatinga . Coa.R.Starm 

Tangent 

Bastings . Ten_R_4t*rm 

Haatinga .Tan_R_3 tarn 

Arctangent 

Haatinga . Arctan  R  (tarn 

Haatinga.  Mod  Arotan  R  tit  arm 

Arcsine 

flka.Aroain  S  6tarm 

rika.Arcain  S  6tarm 

Arccoiina 

Fike .  Arcc  os_9_€t  arm 

Fike .  Arcoos_S  6tenn 
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(2)  Parts  Not  Used 

Over  three-quarters  of  the  CAMP  parts  were  not  used  by  the  1 1th  Missile  Application  (see 
Table  11).  The  primary  reasons  are  (1)  the  1 1th  Missile  Application  did  not  implement  all  the  functions 
for  which  parts  are  designed,  and  (2)  (he  parts  provide  duplicate  implementations  of  some  functions  both 
in  the  baseline  and  tested  versions  (see  Table  15).  A  complete  list  of  the  parts  not  used  is  part  of 
Appendix  A. 


TABLE  15.  SUMMARY  OF  PARTS  NOT  USED  BY  1 1TH  MISSILE 


142 

Mot  applicable 

179 

Duplicate 

20 

Incompatible 

341 

A  part  is  "not  applicable"  if  it  implements  a  function  not  required  by  the  11th  Missile  (e.g., 
logarithm,  Radar_Allimeter).  A  part  is  "duplicate"  if  it  implements  the  same  function  as  a  part  that  is 
used  by  the  1 1th  Missile.  For  example,  (here  are  many  parts  that  compute  the  sine  of  an  angle.  All  sine 
parts  not  used  were  counted  as  duplicates.  A  part  is  "incompatible"  if  it  performs  a  function  required  by 
the  11th  Missile,  but  was  not  used.  The  incompatible  parts  are  further  discussed  below  and  are  sum¬ 
marized  in  Table  16. 

The  11th  Missile  team  chose  statically  sparse  representations  of  some  Kalman  filler 
matrices.  This  required  writing  matrix  operations  (e.g.,  multipliers,  Set_To_ldentity)  tailored  to  the 
representations.  The  first  eleven  of  the  General_Vector_Matrix_Algebra  (GVMA)  parts  listed  in  Table 
16  are  incompatible  because  they  duplicate  the  function  of  these  staticaily-sparse-matrix  operators.  The 
remaining  two  GVMA  parts  (both  named  Change_Element)  were  not  used  because  they  could  be  replaced 
by  simple  assignment  statements.  They  would  have  been  used  if  the  Ada/1750A  compiler  used  by  the 
1 1th  Missile  team  had  implemented  PRAGMA  Inline.  The  Coordinate_Vector_Matrix_ Algebra  Set_To_ 
Zero_Vector  function  was  not  used  for  the  same  reason. 

The  five  Kalman_Filter  parts  listed  were  not  used  because  they  were  limited  to  handling  a 
single  measurement  type  (i.e.,  a  single  type  of  measurement  sensitivity  matrix).  The  11th  Missile  Ap¬ 
plication  had  to  handle  four  types  of  measurements. 

Lateral_Direclional_Autopiiot  was  not  used  because  it  generates  rudder  and  aileron  com¬ 
mands,  and  the  1 1th  Missile  Application  was  not  designed  to  fly  a  missile;  instead  it  drives  a  roll  error 
needle  for  the  pilot  of  a  test  aircraft. 
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TABLE  16.  PARTS  INCOMPATIBLE  WITH  1 1TH  MISSILE 


C«n*ral_V«ctor_Matrix_Algabra 

ABA_Trana_Dynan_9par  aa_Kat  r  ix_Sq_Mat  rix 

ABA_Tran«_Vactor_Sq_Matrix 

VBA_Trana_Vaotor_Soalar 

Dot_Product_Oparationa_Raatrictad 

Matrix_Vaotor_Multiply_Onraatriotad 

Matrix_Vaotor_Multiply_Raatrictad 

V#otor_Matrix_Multiply_Raatrietad 

Dynamioally_9paraa_Matrix_Oparationa_Onoona  trained 
Sat_To_Zaro_Matrix 
Add~To_Idantlty 
Subtraat_rrom_Idantlty 
9at_Io_Idantity_Matrix 

Syamatria_Full_Storaga_Matrix_Oparationa_Conatcainad 

Change_El«oant 

Diagonal_Matrix_Oparation* 

Changa_Claatant 

Coordlnata_Vactor_Matrix_Algabra 
Sat  To  Zaro_Vaotor 

Kalman_Flltar_Data_Typaa 

Kalman_riltar_Conpaat_l_Parta 

Sequent  ially__Update_Covariance_Mat  rix_And_3tata_Vector 
Kalaan_Opdat  a 

Kalaian_riltar_Coeg>liaated_B_Parts 

Sequentlally_0pdate_Covarlance_Matrix_And_State_Veotor 

Kaljaan_Update 

Autopilot 

Lateral_Direotional_Autopllot 


I).  Tested  Version 

The  set  of  CAMP  parts  used  in  the  tested  version  of  the  flight  software  was  identical  to  the  set 
used  in  the  baseline  version.  However,  due  to  compiler  difficulties  (see  Section  VI),  it  was  necessary  to 
make  further  modifications  in  the  tested  version  .  Most  of  the  changes  involved  using  the  CAMP  generic 
code  as  templates  for  constructing  "manual  instantiations",  i.e.,  converting  the  part  to  an  equivalent  non¬ 
generic  version.  Manual  instantiations  were  necessary  whenever  the  compiler  failed  in  compilation  or 
produced  incoirect,  malfunctioning  code  for  a  generic  unit.  The  process  was  carried  out  by  editing 
CAMP  code  via  batch  editing  commands  and  inserting  the  modified  code  into  the  software  in  place  of 
associated  instantiations. 

Virtually  all  of  the  generic  CAMP  parts  in  the  Guid_Computer  software  were  replaced  with 
manual  instantiations.  In  the  Nav_Computer,  a  smaller  proportion  of  generic  units  required  this  treat¬ 
ment.  Tables  17  and  18  list  the  CAMP  parts  which  were  modified  by  manual  instantiation. 

Minor  addilio  al  changes  were  made  to  the  CAMP  Kalman  filter  parts  because  of  the  need  to 
reduce  the  use  of  run-time  stack  storage.  The  Propagate  routine  in  the  Error_Covariance_Matrix_ 
Manager  of  the  Kalman_FiIler_Common_Parts  contained  an  expression  which  proved  to  quite  inefficient. 
A  similar  problem  existed  in  the  Update_Error_Covariance_Matrix_General_Form  routines  of  the 
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TABLE  17.  PARTS  MANUALLY  INSTANTIATED  IN  GUID.COMPUTER 


Abstract  Data  Structures 
Bounded  TITO  Buffer 
Nonblocking  Circular  Buffer 

Coordinate  Vector  Matrix  Algebra 
Cross  Produat 
Vector  Operations 
Vector  Saalar  Operations 

Polynoalals 

Tike  Sesiicircle  Oparations 
Bastings  Radian  Oparations 
Modified  Newton  Raphson  Square  Root 
Reduction  Oparations 

Signal  Processing  Parts 
Absolute  Liadtar 
Lower  Liadter 
Opper  Lower  Limiter 

Waypoint  Steering 

Confute  Turn  Angla  And  Diraetlon 
Coelute  Turning  And  Nontumlng  Distances 
Crosstraak  And  Beading  Merer  Operations 
Distance  to  Current  Waypoint  With  Arosin 
Steering  Veator  Operations 
Turn  Test  Operations 


Kalman_Filter_Compact  and  Kalman_Filter_CompIicated  packages.  The  expressions  in  these  units  con¬ 
tained  operations  over  large  matrix  types.  Unfortunately,  the  compiler’s  allocation  of  temporary  space  for 
operator  results  was  rather  primitive  and  very  inefficient.  In  order  to  improve  efficiency,  the  troublesome 
expressions  had  to  be  split  up  and  evaluated  over  several  assignment  statements.  This  is  discussed  further 
in  Section  VI. 


4.  PARTS  CHANCED 

Twenty-three  Software  Change  Proposals  or  Software  Enhancement  Proposals  were  written  for  the 
CAMP  parts  as  a  result  of  the  1 1th  Missile  development  (see  Table  19).  These  resulted  in  62  changes  to 
53  different  CAMP  parts.  The  changes  consisted  of  20  additions,  34  enhancements,  and  8  "fixes". 
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TABLE  18.  PARTS  MANUALLY  INSTANTIATED  IN  NAV_COMFUTER 


Abatraat  Data  Structures 
Bounded  FIFO  Buf far 
Nonblocking  Circular  Buffar 
Dnboundad  Priority  Queue 

Cull  on  Navigation  Parta 
Dp  data  Velocity 

Bandar  Ailauth  Navigation  Parta 
Coaputa  Coriolia  Acceleration 

General  Vector  Matrix  Algebra 
Column  Matrix  Oparationa 
ABA  Sym  Tranapoaa 
Diagonal  Full  Matrix  Add  Restricted 
Diagonal  Matrix  Oparationa 
Diagonal  Matrix  Scalar  Oparationa 
Matrix  Matrix  Multiply  Raatrictad 

Syaaaatrlc  Full  Storage  Matrix  Oparationa  Conatrainad 
Vector  Vector  Tranapoae  Multiply  Raatrictad 
Vector  Scalar  Oparationa  Conatrainad 

Kalman  Filter  Common  Parta 

Error  Covariance  Matrix  Manager 

State  Transition  And  Procaaa  Noise  Matrioas  Manager 

Kalauut  Filter  Coapact  ■  Parts 
Coaputa  Xalauui  Gain 

Op  date  Error  Covariance  Matrix  General  Fora 
Op  date  state  Vector 

Kalauin  Filter  Cotqplicated  B  Parta 
Confute  Kalman  Gain 

Opdate  Error  Covarlanae  Matrix  General  Form 
Update  State  Vector 
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TABLE  19.  PARTS  CHANGES  AND  ENHANCEMENTS  GENERATED  BY 

THE  1 1TH  M’SSILE  DEVELOPMENT 

(Part  1  of  4) 


r  -  Part  tlxad 
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TABLE  19.  PARTS  CHANGES  AND  ENHANCEMENTS  GENERATED  BY 
THE  1 1TH  MISSILE  DEVELOPMENT 


(Pari  3  of  4) 
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TABLE  19.  PARTS  CHANGES  AND  ENHANCEMENTS  GENERATED  BY 
THE  1 1TH  MISSILE  DEVELOPMENT 

(Concluded) 
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SECTION  IV 


EVALUATION  OF  THE  PARTS  COMPOSITION  SYSTEM 

AND 

ITS  USE  IN  THE  1ITH  MISSILE  APPLICATION 


The  1 1th  Missile  Application  team  designed  and  coded  two  versions  of  the  1 1th  Missile.  The  first 
("Parts  Method")  used  the  CAMP  parts;  this  complete  implementation  of  the  11th  Missile  requirements 
was  covered  in  Section  III.  The  second  ("PCS  Method")  used  the  CAMP  parts  composition  system  (i.e, 
the  AMPEE  system).  This  was  not  a  completely  new  implementation  as  only  the  Kalman  filter  was 
reimplemented  and  unit  tested. 

1.  PRODUCTIVITY 

CAMP  data  indicates  that  a  productivity  improvement  of  up  to  28%  is  possible  using  the  AMPEE 
system  Kalman  Filter  Constructor.  Since  the  PCS  Method  was  not  a  complete  implementation  and  was 
not  integration  tested,  this  is  a  rough  estimate.  PCS-generated  code  and  CAMP  parts  constitute  29.8%  of 
the  PCS  Method  implementation  of  the  11th  Missile  code  (see  Table  20).  The  estimated  productivity 
improvement  uses  the  estimated  cost  of  developing  the  software  without  parts  as  a  basis  (see  Section  III.l 
and  Table  21). 


TABLE  20.  1 1 TH  MISSILE  SIZE  -  PCS  METHOD 


Linas 

State¬ 

of  Coda 

ments 

Operational  Coda 

New 

14707 

8206 

Generated 

2680 

887 

Hod.  Parts 

887 

498 

Parts 

3846 

2481* 

Total 

22230 

12142 

*  Estimated 

The  reduction  in  the  detailed  design  and  coding  phase  was  estimated  as  follows: 

DDJSaved  =  DD_Rate  x  ( GenjCode  +  Parts jCode)  -  PCSjCost 
DDJSaved  =  0.0762  hr/LOC  x  (2680  LOC  +  3946  LOC)  -  13  hr 
DD_Saved  =  492  hr 

where  DD_Saved  =  Detail  design  and  code  effort  saved,  hours 

DD_Rate  =  Detail  design  and  code  productivity,  hours  per  line-of-code 
GenCode  =  Generated  code,  lines-of-code 
Parts_Code  =  Parts  code,  lines-of-code 
PCS_Cost  =  Cost  of  using  PCS,  hours 

DD_Rate  is  from  Section  III.l.  The  PCS_Cost  is  the  lime  spent  at  the  PCS  generating  the  Kalman 
filter,  plus  the  time  spent  writing  the  code  to  interface  the  generated  code  to  the  rest  of  the  Parts  Method 
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TABLE  21.  ESTIMATED  EFFECT  OF  PCS  ON  1 1TH  MISSILE  EFFORT 


Effort  (hour*) 


Phaaa 

Eatlmatad 

Without 

Parta/PCS 

Eatlmatad 

With 

Parta/PCS 

Raquiraaaanta 

708 

708 

Archltaatural 

Daaign 

883 

883 

Dat .  Daaign  C 

Coda 

1804 

1112 

Taating 

3228 

2247 

Othar 

371 

371 

Total 

6784 

3321 

Effort  Savad:  1473  houra 
Productivity  Inqorovamant :  28% 


code  (mostly  renaming  instantiations  and  types).  Titus,  the  13  hour  cost  includes  some  extra  work, 
because  a  "from  scratch"  application  would  not  require  the  interface  code.  On  the  other  hand,  another 
development  team  would  not  be  as  familiar  with  the  PCS  and  the  parts  as  the  11th  Missile  team;  this 
would  drive  the  cost  up. 

The  test  effort  that  could  be  saved  was  estimated  similarly; 

Test_Saved  =  Test_Rote  x  ( GeiijCode  +  PartsjCode) 

Test_Saved  =  0. 148  hr/LOC  x  (2680  LOC  +  3946  LOC) 

TestJSaved  ~  981  hr 

where  Test_Saved  =  Test  effort  saved,  hours 

Tesl_Rate  =  Test  productivity,  hours  per  line-of-code 
GenCode  =  Generated  code,  lines-of-code 
Parts_Code  =  Parts  code,  lines-of-code 

Tes!_Rate  is  from  Section  III.  1 .  This  estimate  assumes  that  the  parts  and  the  PCS-generated  code 
would  not  be  unit  tested.  Under  this  assumption,  none  of  the  lest  code  would  have  been  CAMP  parts,  so 
no  credit  is  given  for  that.  Also,  as  in  Section  1II.1,  this  estimate  ignores  the  other  costs  of  using  the  parts 
and  the  PCS.  Therefore,  28%  is  a  ceiling  on  the  possible  improvement  in  productivity  to  be  gained  from 
using  the  Kalman  Filter  Constructor. 

2.  PCS:  WHERE  IT  WAS  USED 

The  Kalman  Filter  Constructor  was  the  only  AMPEE  system  facility  used.  The  PCS-generated  code 
and  the  parts  instantiated  by  it  constitute  70.1%  of  the  Kalman_Filter  LLCSC  (compared  to  24.4%  with 
the  Parts  Method).  The  new  (i.e.,  not  parts  or  PCS-generated)  KaIman_Filter  code  was  the  same  for  both 
methods,  with  two  exceptions: 

•  The  amount  of  new  code  that  defines  types  and  operators  was  greatly  reduced  with  the  PCS 
Method.  The  PCS  generated  most  of  the  type  descriptions,  all  of  the  sparse-matrix  operators,  and 
all  of  the  operator  instantiations. 
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•  The  PCS  Method  required  new  code  to  rename  procedures  written  or  instantiated  by  the  PCS.  This 
was  required  to  make  the  PCS-generated  code  compatible  with  the  rest  of  the  Parts  Method  im¬ 
plementation. 

3.  PARTS:  USED,  MODIFIED,  UNUSED,  AND  WHY 

The  PCS  Method  used  the  same  set  of  parts  as  the  Parts  Method  with  one  exception  (see  Table  22). 
The  exception  occurred  because  the  PCS  used  a  part  that  was  written  after  the  Parts  Method  code  was 
designed.  The  new  part  allowed  the  user  to  instantiate  a  vector* scalar*  vector-transpose  operation,  instead 
of  having  to  write  one  using  the  vector*vector-transpose  part. 

TABLE  22.  SUMMARY  OF  CAMP  PARTS  USAGE  -  PCS  METHOD 


Parts  Os ad  96 

Parts  Osad  with  Modification  16 

Parts  Mot  usad  341 

453 

Usad  24.7%  of  Parts 
Osad  23.3%  of  Parts  Linas-of-Coda 


4.  PCS:  PROBLEMS 

The  Kalman  Filter  Constructor,  as  currently  implemented,  has  two  major  options  for  representation 
of  Kalman  matrices:  full  or  sparse.  The  full-matrix  code  uses  less  instruction  memory,  but  more  operand 
memory  and  is  relatively  slow.  The  sparse-matrix  code  uses  much  more  instruction  memory,  but  is 
relatively  fast.  In  the  case  of  the  11th  Missile  Application,  the  generated  sparse-matrix  code  caused  the 
program  to  exceed  the  64K-word  instruction  memory  limit  imposed  by  the  compiler.  The  full-matrix 
code,  had  it  been  generated,  would  have  been  very  similar  to  the  Parts  Method  implementation,  which 
also  exceeded  the  64K-word  operand  memory  limit  imposed  by  the  compiler.  As  a  result,  PCS-generated 
code  was  not  hardware-in-the-loop  tested. 

One  or  more  options  that  generate  code  with  intermediate  speed  and  memory  usage  must  be  added  to 
the  Kalman  Filter  Constructor.  One  possibility  is  to  represent  F  as  an  array  of  records,  where  each  record 
includes  a  set  of  matrix  indices  and  the  value  of  the  corresponding  matrix  element  (see  Figure  14). 

Another  project  at  MDAC-STL  used  the  PCS  to  generate  a  17-state  Kalman  filter  for  a  flight 
demonstration  of  a  GPS-aided  navigation  system.  The  application  used  a  ruggedized  MicroVAX  with 
eight  megabytes  of  physical  memory.  The  PCS-generated  sparse-matrix  code  worked  well  in  this  ap¬ 
plication. 
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typa  kilnin_«lmnti  la  dlglta  9; 

type  atataa  la  (x_poa,  y  poa ,  a_poa, 

x_jral,  y_yal,  *_val, 

E_aoo, 

x_att,  y_att,  *_att, 

x_gyro_blaa,  y_gyro_blaa,  a_gyro_blaa, 
x_aoa_bla« ,  y_aaa_blaa,  «_aoa_biaa, 
y_aoo_aoala,  *_aao_aa«Xa, 
prop_l ,  prop_2,  prop_3)  ; 

typa  f_al«wnts  la 
racord 

row  :  atataa; 
aol  :  atataa; 
valua  :  kalaan_alaa»nta; 
and  raaord; 

f  alia  :  aonatant  7<; 

typa  f_lndloaa  la  naw  lntagar  ranga  1  . .  f_al*a; 
typa  f_matricaa  la  array  f_lndloaa  of  f_alaaanta; 

Figure  14.  Possible  New  Representation  of  Kalman  Matrix 
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SECTION  V 


EVALUATION  OF  ADA 

AND  ITS  USE  IN  THE  IITH  MISSILE  APPLICATION 

The  CAMP  1 1th  Missile  Application  served  as  a  proving  ground  not  only  for  the  CAMP  parts,  but 
also  for  the  Ada  language.  This  section  shows  that  Ada  is  effective  for  real-time  embedded  applications 
and  that  the  "optional"  features  of  (he  language  must  be  implemented. 

Ada  was  shown  to  be  an  effective  language.  The  1 1th  Missile  Application  required  only  21  lines  of 
assembly  code  —  0.1%  of  the  total  application  code.  No  assembly  code  would  have  been  required  if  the 
Start-up  ROM  software  had  been  designed  to  interface  to  the  Ada  compiler’s  Run-Time  System.  This  is 
particularly  impressive  in  view  of  the  low-level  machine-interface  functions  implemented. 

1.  EFFECTIVENESS  OF  ADA  FOR  MACHINE  INPIJT/OUTPUT  -  AN  EXAMPLE 

The  effectiveness  of  Ada  for  low-level  machine-interface  functions  was  demonstrated  by  the  fact 
that  the  Bus  Interface  Module  (BIM)  Interface  was  coded  entirely  in  Ada. 

a.  Description  of  the  Bus  Interface  Module  (BIM)  Interface 

The  Bus  Interface  Module  (BIM)  is  a  hardware  device-controller  comprising  a  Motorola  68000 
microprocessor  and  associated  circuitry  packaged  on  a  single  card.  It  receives  and  sends  messages  on  a 
MIL-STD-1553B  data  bus,  places  messages  into  1750A  memory,  and  receives  messages  from  the  1750A. 

A  BIM  may  be  operated  in  one  of  two  modes:  Bus  Controller  (BC)  or  Remote  Terminal  (RT). 
A  Bus  Controller  polls  all  terminals  (including  itself)  on  the  bus  and  sends  transmit  and  receive  com¬ 
mands  to  other  terminals  as  required.  The  BIM  communicates  with  the  1750A  via  a  command  port, 
interrupts,  and  direct  memory  access  (DMA).  With  the  exception  of  the  command  word,  all  data  transfers 
are  via  DMA  (see  Figure  15). 

The  1750A  issues  commands  to  the  BIM  via  a  bit-mapped  16-bit  output  register  (see  Table  23). 
The  register  is  accessed  by  a  Programmed  Output  (PO)  instruction;  its  address  is  610  (for  a  RT)  or  620 
(for  a  BC).  CommandStatus  (see  Figure  15)  is  updated  each  time  the  BIM  responds  to  a  command,  and 
ErrorStatus  is  updated  whenever  there  is  a  problem  receiving  a  message.  The  two  status  words  are 
bit-mapped  and  have  the  same  format  (see  Table  24).  Index  indexes  Input _PTR,  an  array  of  16  pointers  to 
input  messages.  When  an  input  message  is  received,  the  BIM  increments  Index,  then  copies  the  message 
to  the  address  specified  by  InputPTR(Index).  Output _Ptr  points  to  an  output  message.  The  BIM  reads  it 
when  commanded  to  transmit  a  message,  then  reads  the  message.  P  oiling _List  is  an  array  containing  a 
polling  sequence.  It  is  used  only  by  a  BC,  and  only  if  the  polling  sequence  is  being  changed. 

The  1750A  addresses  of  Command  Status,  Error  Status,  Index,  Input  Ptr,  Output _Ptr,  and 
Polling_List,  are  among  the  items  specified  in  a  BIM  Initialization  Block  (see  Table  25).  When  the  BIM 
is  initialized,  the  address  of  the  initialization  block  is  sent  to  the  BIM  via  the  command  port. 
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Command  Register 


Command 


(Initialization  Block) 
Commandos tatus  address 
ErrorjStatus  address 
Index  address 
Input_PTR  address 
Output_Ptr  address 
Polling_List  address 


Command_Status 
Brror_Status  — 
Index  - 


Input_Data  address 


Output_Data  address 
Input_Data  - 


Output_Data 

Polling_List 


(Initialization  Block) 
Connand_Status  address 
Error_Status  address 
Index  address 
Input  PTR  address 
Output_PTR  address 
Polling  List  address 


>  Command_Status 
Error_Status 

>  Index 
Input_PTR(0) 
Input  PTR(l) 


Input_PTR(15) 
Output_PTR 

Input_Data 

OutputJData 

Polling_List 


Figure  15.  BIM/1750A  Interface 


TABLE  23.  BUS  INTERFACE  MODULE  COMMAND  WORD 


Command  Word  Format 

Bit(s) 

Field 

Description 

00 

OD 

1  =>  Output  Data  (send  message) 

01 

SP 

1  =>  Stop  Polling 

02 

CP 

1  =>  Change  Polling  Sequence 

03 

CM 

1  =>  Change  Number  of  Message  Retries 

04 

RP 

1  =>  Restart  Polling 

05 


B 


I  =>  Perform  BIT 


06-09 


Initialize:  0101  for  the  first  command,  1010  for  the  second 


10 


RS 


Restart  from  Timeout 


TABLE  24.  BUS  INTERFACE  MODULE  STATUS  WORD 


Status  Word  Format 

Bit(s) 

Field 

Description 

00 

PA 

1  =>  Polling  Active 

01 

MM 

Module  Mode:  0  =>  bus  controller,  1  =>  remote  terminal 

03 

MI 

1  =>  Module  Initialized 

04 

CPU 

BIT  result:  1  =>  CPU  Error 

05 

CS 

BIT  result:  1  =>  Checksum  Error 

06 

1M 

1  =>  Invalid  Message 

07 

IV 

1  =>  Invalid  Transmit  Vector  Word 

08-12 

RT 

RT  associated  with  IM  or  IV 

13 

TI 

1  =>  Time-out  Error 
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TABLE  25.  BUS  INTERFACE  MODULE  INITIALIZATION  BLOCK 


[  Initialization  Block  Format 


05 


06 


06 


07 


08 


08 


09 


10 


10 


11 


12 


12 


13 


14 


15 


15 


16 


17 


18-  18+N-l 


18+N  -  I8+N+M-I 


Bit(s) 

Description 

00-15 

Initialization  Block  Word  Count 

15 

Module  Mode:  0  =>  BC,  1  =>  RT 

11-15 

Terminal  ID 

08-11 

lnput_PTR  address  state 

12-15 

Input_PTR  processor  state 

00-15 

Input_PTR  address 

12-15 

Maximum  index  value  (length  of  array  Input_PTR) 

08-11 

Output_PTR  address  state 

12-15 

Output_PTR  processor  state 

00-15 

Output_PTR  address 

08-11 

Command_Status  address  state 

12-15 

Command_Status  processor  state 

00-15 

Command_Status  address 

08-11 

Error_Status  address  state 

12-15 

Error_Slatus  processor  state 

00-15 

Error_Status  address 

08-11 

Index  address  state 

12-15 

Index  processor  state 

00-15 

Index  address 

00-15 

Number  of  Message  Retries  (BC  only) 

08-11 

Polling_List  address  state  (BC  only) 

12-15 

Polling_List  processor  state  (BC  only) 

00-15 

Pol!ing_Lisl  address  (BC  only) 

11-15 

Number  of  valid  terminal  IDs  (BC  only) 

11-15 

Terminal  IDs  (N  entries,  BC  only) 

00-15 

Polling  Sequence  (M  entries,  BC  only) 

Input  Ptr  is  the  most  extreme  example  of  indirect  addressing  in  the  BIM  interface:  triple-nested 
pointers.  The  top-level  pointer  is  to  Ihe  BIM  Initialization  Block.  The  block  contains  a  pointer  to 
Input_Ptr  (second  level),  where  lnput_Ptr  is  an  array  that  points  to  the  actual  message  locations  (third 
level). 

There  are  two  interrupts  for  each  BIM.  The  input  interrupt  (level  1 1  for  BC,  13  for  RT)  signals 
that  a  message  has  been  transferred  to  1750A  memory.  The  output  interrupt  (level  12  for  BC,  14  for  RT) 
signals  that  an  output  message  has  been  sent  over  the  bus  and  that  the  BIM  is  ready  to  accept  another 
output  message. 

b.  Ada  Solution  to  the  BIM  Interface 

The  BIM  interface  presents  a  significant  challenge  to  a  higher-order  language  programmer.  In 
the  past,  the  use  of  interrupt  handlers,  a  bit-mapped  command  port,  bit-mapped  status  words,  and  pointers 
(including  double-  and  triple-nested  pointers)  would  have  required  programming  in  assembly  language. 
Ada’s  access  types  and  representation  specification  features  made  it  possible  to  program  the  BIM  inter¬ 
face  entirely  in  Ada. 

The  interrupt  handlers  were  implemented  as  Ada  tasks  with  interrupt  entries  (see  Figure  16). 

taak  Input_Xntarnipt_landlar  la 

FRAOM&  Priority  (11); 

antry  Interrupt ; 

for  Interrupt  usa  at  13; 

and  Input_Zntarrupt_landlar; 

Figure  16.  Use  of  Interrupt  Entry 

The  command  port  was  modeled  as  a  record,  with  the  bit-map  defined  by  a  record  represen¬ 
tation  clause  (see  Figure  17).  This  code  example  demonstrates  the  use  of  several  optional  features  of 
Ada:  change  of  representation  (short_boolean  and  memory.states),  size  clauses  for  both  scalar  and 
record  types,  enumeration  representation  (init.commands),  record  representation,  and  nested  represen¬ 
tations  (both  command_words  and  its  components  have  representation  specs).  The  example  also  shows 
the  use  of  an  Ada  predefined  constant  to  make  (he  code  compiler-independent.  Using 
System.storage_unit  ensured  that  the  representation  clauses  would  work  for  either  an  8  or  16  bit  storage 
unit. 


The  command  port  was  accessed  via  package  Low_Level_IO.  Low_LeveI_IO,  which  was 
provided  by  the  compiler  vendor,  had  to  be  slightly  modified  because  the  command  port  address  (610  or 
620)  is  not  in  the  legal  range  defined  by  MIL-STD-I750A. 

Figure  18  shows  how  the  BIM  Initialization  Block  was  coded.  This  example  shows  more  of  the 
power  and  flexibility  of  Ada.  The  block  was  coded  as  a  variant  record,  with  a  representation  clause 
specifying  locations  of  the  components.  Not  shown  are  the  type  definitions  of  the  component  types 
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with  Syat an; 

pack aga  Rapraaantation_Paranatara  ia 

maaaaga_word_aiza  i  oonatant  :»  IS;  --  bita 

atoraga  unlta  par  word  :  conatant  :■  maaaaga_word_alza/9yataa>. atoraga_unit 
and  Rapraaantation_Paramatara; 


packaga  BIM_Intarfaca_Typaa  ia 

typa  ahort  boolaan  ia  naw  boolaan; 
for  ahort_boolaan' aira  uaa  1; 

and  BIM_Intarf aoa_Typaa  ; 


with  BIM_Xntarf aca_Typaa  ; 
with  Rapraaantation_Paraaiatara ; 
packaga  BIM_Intarfaaa_Hlddan_Typaa  ia 

packaga  BIT  ranaaiaa  BIM_Intarfaaa_Typaa; 

packaga  RP  rananan  Rapraaantatlon_Faraaatara; 

typa  init_conaaanda  ia  (not_init_cnd,  init_cmd_l,  init_aai_2) ; 

for  init_comaanda  uaa  (not_init_amd  ">  0, 

init_a*d“l  ->  2 #0101#, 
lnit_cnd_2  ->2#1010#); 

for  inlt_aonaaanda<  alia  uaa  4; 

typa  mamory_atataa  la  naw  intagar  ranga  0..15; 

for  MBK>ry_atataa' alia  uaa  4; 

typa  oonmand_worda  ia 
raaord 

output_data 
•top_polling 
changa  polling  aaquanca 
changa_maa  a  aga_r  at  r  1  aa 
raatart_polllng 
parfona_BIM_BIT 
lnitialiaa 
r aa t a r t_f r om_t  iaaou t 
ammory_atata 
and  raaord; 

for  aonmand_wordz  uaa 
racord 

output_data  at  0*RP . atoraga_unita_par_word  ranga  0..  0; 

atop_polling  at  0*RP ,  atoraga  unita  par  word  ranga  1..  1; 

ahanga_polling_aaguanca  at  0*RP . atoraga_unita_par_word  ranga  2..  2; 

changa_naaaaga_ratrlaa  at  0*RP . atoraga_unita_par_word  ranga  3..  3; 

raatart  polling  at  0*RP . atoraga_unita_par_word  ranga  4..  4; 

parform_BZM_BIT  at  0*RP , atoroga_unita_par_word  ranga  3..  3; 

lnitialiaa  at  0*RP . atoraga_unita_par_word  ranga  9; 

rnatart_from_tininout  at  0*RP .  atoraga_unit#_par_word  ranga  10..  10; 

mamory_atata  at  0*RP . atoraga_unlta_par_word  ranga  12..  13; 

and  raaord; 

for  ooimiand_words' aizo  uaa  IS; 
and  BIM_Intarfaaa_Hlddan_Typaa; 


Figure  17.  Example  of  Record  Representation  Clause 


BIT . ahort_boolaan 
BIT . ahort_boolaan 
BIT . ahort_boolaan 
BIT. ahort_boolaan 
BIT . ahort_boolaan 
BIT . ahort_boolaan 
lnit_ooananda 
BIT. ahort  boolaan 
naa«ry_a  tataa 


BIT. falaa; 
BIT. falaa; 
BIT. falaa; 

:■  BIT. falaa; 

:»  BIT. falaa ; 

BIT. falaa; 

:■  not_lnit_carf; 
BIT . falaa; 

0; 
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within  the  initialization  block;  as  with  the  components  of  Command_Word,  these  also  had  representations 
specified.  In  addition  to  representation  clauses,  access  types  were  used  for  addresses  of  data  objects. 

2.  INEFFECTIVENESS  OF  ADA  FOR  OPERATING  SYSTEM  INTERFACE 

This  section  examines  where  assembly  language  was  used  in  the  11th  Missile  Application.  It  will 
show  that  Ada  was  not  effective  when 

•  Code  must  run  before  the  Ada  Run-Time  System  starts,  or 

•  Machine  code  must  be  at  a  specified  memory  location. 

Nineteen  of  the  21  lines  of  assembly  code  in  the  llth  Missile  Application  were  in  module  Reset_ 
Sys_Enable_ROM  (see  Figure  19).  This  module  interfaces  with  the  Start-up  Real-time  Multi-tasking 
Operating  System  (SURMOS).  Reset_Sys_Enable_ROM  contains  both  the  first  code  and  the  last  code  to 
be  executed  from  RAM. 

SURMOS  is  a  ROM-resident  operating  system  used  at  power-up  to  provide  basic  services;  perform¬ 
ing  built-in  tests,  BIM  initialization  and  control,  telemetry,  and  downloading  the  1 1th  Missile  Application 
software  to  RAM. 

SURMOS  was  designed  to  interface  with  the  original  Real-time  Multi-Tasking  Operating  System 
(RMOS)/JOVIAL  implementation  of  the  llth  Missile  Application.  It  was  used  without  modification  for 
the  Ada  implementation.  If  SURMOS  had  been  designed  to  interface  with  the  Ada  Run-Time  System,  it 
probably  would  not  have  been  necessary  to  code  the  llth  Missile  interface  to  it  in  assembly  language. 
However,  as  written,  SURMOS  does  not  transfer  control  to  the  location  expected  by  the  Ada  Run-Time 
System,  nor  does  it  leave  appropriate  values  in  the  page  registers. 

RAM  and  ROM  execute  in  the  same  address  space.  For  example,  if  the  instruction  counter  is  40 
(hex),  either  ROM  address  40  or  RAM  address  40  will  be  execute  1,  depending  on  whether  ROM  is 
enabled  or  disabled.  At  power-up,  ROM  is  enabled.  When  SURMOS  is  commanded  to  start  the  applica¬ 
tion  software,  it  executes  an  instruction  at  location  3E  to  disable  ROM  (see  Figure  20).  Because  the 
hardware  "pre-fetches"  the  next  instruction,  it  will  then  execute  the  instruction  at  location  40  in  ROM, 
which  is  a  branch  to  location  40.  This  means  the  first  instruction  of  the  1 1  lb  Missile  code  to  be  executed 
must  be  located  at  address  40  (hex)  in  RAM.  The  Ada  Run-Time  System  expects  control  to  be  trans¬ 
ferred  to  location  0. 

SURMOS  does  not  leave  the  page  registers  in  the  power-on  reset  state,  which  is  a  1-to-l  correspon¬ 
dence  between  physical  and  logical  memory.  Since  the  Ada  Run-Time  System  expects  the  page  registers 
in  the  reset  stale,  the  initialization  code  must  set  the  page  registers.  This  is  done  in  the  PR_LOOP  (see 
Figure  19). 

Finally,  (he  slarl-up  code  loads  the  initial  status  (the  LST  INIT_STATUS  instruction).  This  restores 
the  status  (interrupt  mask,  status  word,  and  instruction  counter)  to  the  power-up  state  and  results  in  a 
branch  to  location  zero,  which  transfers  control  to  the  Ada  Run-Time  System  code. 

Control  may  be  returned  to  SURMOS  at  location  44.  To  do  this,  the  llth  Missile  Application  must 
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typ«  Initialisation^  look 

(bimjaoda  :  nodula_modaa  :  ■  Irat^ooatrtllur; 

taxmlnala  :  nunbar_of_tamlnala  :■  1)  la 

raoord 

word_oount  r  word<j3ounta_r*nga; 

ttralaal^ldjiib  :  BT_XD_n*b_oonatant  :  ■  1; 

tarminal_id  :  BT.tarmlnala; 

input_ptr*_blk_AJ  :  nanory_at*taa; 

input_ptra__blkJPi  :  — o  ry_it«Ui; 

lnput_j>tra__blk_addr  :  Input  ptr»  blook  ptr»; 

no_of__lnput_buf  for*  :  ladax_word; 

output_ptr_kl  :  aaaocy^itiUi; 

output_j>t  r_PS  :  mncy^atitai; 

outpot  ptr  addr  :  output _j>tro_addr_typa; 

aoaatad^atatua^M  :  mama ry^atataa ; 

acMtod^atataa^PI  :  me ry__atataa ; 

qn—an  d_atatu«_addr  :  atatua_word_ptra ; 

•rror _ atatua_JUi  :  aaaory_itata>; 

•rror^itataa^fl  :  mama ; 

arror_s t atu  a_addr  :  status_wordjptra ; 

lnpat^lndaijM  :  — n  ry_atatoa ; 

lnput_ind*i^FI  :  nanory__atatas; 

lnput_lndnx_addx  s  input_ind*r_oddr_typa; 

oaaa  bimjaoda  la 

whan  bu*_eomtrollar  ■> 

ratrlaa  :  r*trlaa_fcyp«; 

p*w_pol  lrotr laa  AJ  :  nan  n  ry_at ataa  ; 
ni>  pollratrlouPS  :  n—n  ry_ot  ataa ; 
naw_poll_rotrio«_addr  :  n*w_poll_ratri#*_addr__typa 

:■  nav  aawpoll  ratrlaa  blook; 
tarmlnal  ldo_oount  :  n«bar_ol  tarmlaala; 
rt__ld«_uid_po  1  l_aaq  :  I DC_RT_tndj) o  1  l_word»_l  1  at ; 

whan  othara  ■> 
null; 
and  oaaa; 
and  raoord; 

for  Xnltiallsatlon_Blook  uaa 
raoord 

word_oount  at  0*B» .  *torag#jinltajpar_word  ran  fa  0  ..  19; 

bim_moda  at  1  *RF .  atorag*jmlta_par_ward  ran  fa  19  ..  19; 

tormina  l__ld_msb  at  2  *W .  ■toragaunltaparword  ranfa  11  . .  11; 

tarmlnal_ld  at  2**P .  »toraga_unlta_por_word  ranfa  12  ..  19; 

lnput_ptr  a_bl k_W  at  3*BJP . atoragajxnlt* jpar_word  ranfa  9  ..  11; 

Input jptr#_blkJTB  at  3*W .  atorag •_unita_jpar_word  ranfa  12  ..  19; 

Input jptra_blk_addr  at  4*RV.  atoraf*_ualta_par_ward  ranfi  0  ..  19; 

n o_of _input_buf fa ro  at  5**1 .  atoraf*_unlta_jp*r_word  ranfa  12  ..  19; 

output_ptr_AS  at  l*BB.  atoragajialtajparjford  ranfa  9  . .  11; 

output_ptr_Pl  at  i*BB.atoragnjmita_apar_i*ord  ranfa  12  . .  19; 

outf'it_ptr_*ddr  at  7 . otoraf o  unlt o_par_word  ranfa  0  ..  19; 

a«nnaad_0tataaiJfcB  at  9  *Rf .  at  or  aga_un  It  o_par_word  ranfa  •  11; 

o  r— an  rt_atatua_P8  at  9*B> .  storagnjinltajparjiand  .ranfa  12  ..  19; 

ooMand_atatua_addr  at  MAP .  rtoragojinit »_par_word  ranfa  0  ..  19  r 

arror_otatu*_AB  at  10*ftP.atoraga_unlta_par_ward  ranfa  i  ..  11; 

arror_atatua_BB  at  10+BP .  «toraga_unlt*_par_word  ranfa  12  ..  19; 

arror_*tatua_addr  at  11*RI .  ttoraga^unitajpor^word  ranfa  0  ..  19; 

input_indar_JUI  at  12*RV . atoragojinlt  a_j>ar_*ord  ranfa  •  11; 

lnput_indax_PB  at  12*W, at  or  agajrn  It  a__pa  reward  ranfa  12  ..  19; 

lnput_indar_addr  at  13*M .  at or ago  unltaporword  ranfa  0  ..  19; 

ratrlaa  at  14*M .  atoraga  unit  a  par  ward  ranga  0  .,  19; 

now__poll_ratriaa_Jk8  at  13*RF.  storagojmlta__pnr__word  ranga  I  . .  11; 

n*w_poll_ratrlaa_P8  at  15*1tP.  sterago_unlta_par_word  ranga  12  ..  19; 

n*w_poll_rotrlaa_addr  at  1J*M .  •toraga_unlta_par_wozd  ranga  0  . .  IS; 

tormina  l_ida_aount  at  17*W .  ■torag#_unita_par_woxd  ranga  11  ..  19; 

rtldiandpo  lloaq  at  lt*AP .  ■torago_unlta__par_woxd  ranga  0  ..2909; 

and  raoord; 


Figure  18.  Representation  Clause  for  Variant  Record 
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MODULI  RE3ET_STS_ENABLE_R0M 
RESET  STS  ENABLE  ROM  CSECT  ABSOLUTE-00070 


INIT_3TATU3 

DATA 

OOOOO 

DATA 

00000 

DATA 

00000 

TRANSrER_VECTOR 

CSECT  ABSOLUTE-00040 

MOP 

BR 

START_UP 

XIO 

0, ESUR 

BRANCH_SELF 

BR 

BRANCH  SELF 

START_UP 

LISP 

0,  OF 

LISP 

1,  OF 

PR__LOOP 

XIO 

o, wipr, i 

XIO 

O.WOPR.l 

SISP 

0,1 

SISP 

1,1 

BSE 

PR_LOOP 

L9T 

INI  T_S  TATU  3 

END 

;  SURMOS  ractora  40 


;  Vaotor  to  SURMOS  »t  44 
;  Fix  up  pag*  rogiatara 


;  Go  to  0,  start  program 


Figure  19.  Module  Reset_Sys_Enable_ROM 


ROM  RAM 


00 

• 

• 

3E 

Disabla  ROM 

40 

Branch  to  40 

Branch 

to  Agpl 

42 

•  • 

Enabla 

ROM 

44 

Continue 

Branch 

to  44 

Figure  20.  SURMOS  Interface 

have  an  instruction  at  location  42  to  enable  ROM  (XIO  0,  ESUR),  followed  by  a  branch  to  location  44 
(BR  BRANCH_SELF).  Two  alternate  approaches  were  briefly  investigated. 

Since  XIO  instructions  may  be  executed  via  Package  Low_Leve!_IO,  it  would  seem  possible  to  code 
this  module  entirely  in  Ada.  however,  most  of  Reset_Sys_Enable_ROM  executes  before  the  Ada  Run¬ 
Time  System  starts  up.  Low_Level_IO  cannot  be  executed  until  after  the  page  registers  have  been 
cleaned  up  and  a  slack  has  been  established.  The  code  that  enables  ROM,  the  only  part  of  the  module  that 
does  execute  after  the  Run-Time  System  has  started,  must  have  the  XIO  instruction  placed  at  location  42. 
This  would  not  be  possible,  since  the  XIO  would  be  executed  from  the  body  of  a  Low_Level..IO  proce- 
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dure.  Finally,  (he  module  would  have  had  to  start  at  an  address  smaller  than  40  (hex),  since  there  would 
have  been  some  preliminary  code  before  the  first  instruction  in  the  procedure  body.  This  would  have 
overwritten  the  interrupt  transfer  vectors  that  must  be  in  locations  20-3F  (hex). 

The  other  approach  would  have  used  machine-code  insertion  within  an  Ada  subprogram.  This 
would  still  be  using  assembly  language,  but  would  have  had  the  advantage  of  "burying"  it  in  an  Ada 
module,  which  would  put  the  module  under  the  control  of  the  Ada  library  system.  Unfortunately,  the 
compiler  did  not  implement  address  clauses  for  subprograms,  so  linker  instructions  would  have  been 
required  to  start  the  module  at  location  40.  This  approach  was  rejected  because  it  would  still  be  program¬ 
ming  in  assembly  language  and  would  have  required  the  additional  complication  of  special  linker  instruc¬ 
tions. 

The  remaining  two  lines  of  assembly  language  code  were  machine  code  insertions  (see  Figure  21). 
These  instructions  branch  to  location  40  (to  restart  the  11th  Missile  Application)  and  location  42  (to 
enable  ROM,  thereby  terminating  the  application).  Machine-code  insertion  was  suitable  because  these 
instructions  are  executed  after  (he  Run-Time  System  has  started  and  do  not  need  to  be  in  specific  loca¬ 
tions. 


with  Much  ln»_Cod« ; 
uh  Meehine_Code; 

pwk>ji  body  SyitM*_Cont roller  is 

procedure  PreperetoDownloed  la 
begin  —  PreperetoDownloed 
JC_r»t ' (Opcode  ■>  Jo, 

C  ->  uno, 

RX  ■>  RO, 

Addr  «>  1C#0042| ) ; 

end  PreperetoDownloed; 

procedure  Wematert  le 
begin  —  WenoStert 

JC_ret ' (Opcode  ->  Jo, 

C  ■>  uno, 

RX  «>  RO, 

Addr  ->  1«#0040#), ■ 

end  WeneStert; 
end  9yeten_Controller; 


Figure  21.  Machine  Code  Insertion 
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3.  USE  OF  OPTIONAL  FEATURES 


Optional  ("Chapter  13")  features  of  Ada  were  used  extensively  in  the  1 1th  Missile  Application.  The 
preceding  discussion  of  the  BIM  Interface  functions  clearly  shows  that  most  of  these  features  are  not 
optional  for  real-time  embedded  applications.  Table  26  lists  the  Chapter  13  features  of  Ada  and  indicates 
which  ones  were  used.  Comments  on  some  of  the  options  follow. 

It  was  not  necessary  to  specify  the  storage  size  of  an  array  in  order  to  force  blank  spaces  between  the 
components.  Instead,  the  11th  Missile  team  did  it  by  making  the  array  components  records  and  specify¬ 
ing  the  length  of  the  records. 

The  1 1th  Missile  team  would  have  used  the  size  representation  clause  for  access  types  if  it  had  been 
implemented.  The  BIM  read  32-bit  addresses,  but  the  access  types  on  the  1750A  are  16  bits.  This  was 
gotten  around  by  defining  a  32-bit  record  containing  the  access  type  in  the  second  16  bits  (see  Figure  22). 

Storage_size  was  used  to  specify  the  stack  sizes  of  the  tasks.  This  was  crucial  for  the  Navigation 
CSC  and  points  up  a  useful  programming  hint:  always  specify  tasks  by  defining  a  task  type  and  then 
declaring  an  instance  of  the  type,  otherwise,  storage  size  cannot  be  specified. 

The  1 1th  Missile  team  would  have  used  the  small  attribute  to  fix  the  value  of  the  least-significant-bit 
of  fixed-point  types  if  it  had  been  implemented.  Representations  can  be  forced,  however,  by  specifying 
the  accuracy,  range,  and  size  of  fixed-point  types  (see  Figure  23). 

If  address  specification  for  subprograms  had  been  implemented,  the  Uth  Missile  Application  may 
have  been  able  to  place  the  start-up  code  at  location  40  (see  Section  V.2).  Machine  code  insertion  would 
still  have  had  to  been  used,  but  at  least  the  assembly  language  would  have  been  buried  in  the  body  of  an 
Ada  subprogram. 

It  was  not  necessary  to  use  PRAGMA  Interface.  In  the  cases  where  the  code  did  interface  to  as¬ 
sembly  language,  it  branched  to  the  assembly  statements  with  a  machine-code  insertion. 
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TABLE  26.  USE  OF  OPTIONAL  ADA  FEATURES  BY  1 1TH  MISSILE 


1 1th  Missile  Usage  of  Optional  Ada 


Option 


Length  Clauses 


Integer 


Enumeration 


Fixed  Point 


Features 


Floating  Point 


Record 


Access 


Storage_Size 


Small 


Enumeration  Representation 


Record  Representation 


Alignment 


Component 


Address 


Objects 


Subprogram 


Package 


Task 


Entry 


Change  of  Representation 


Package  System 


Named  Numbers 


Representation  Attributes 


Representation  Attributes  of  Real  Types 


Machine  Code  Insertion 


Interface  to  Other  Languages 


Unchecked  Programming 


Unchecked_Deallocation 


Unchecked  Conversion 


13.10.1 


13.10.2 


typa  long_input_»a*aaga_ptra  la 
raoord 

duaaty  :  BIT .  lnput_maaaagajptra; 
ptr  :  BIT . lnput_maaaaga_ptra; 
•nd  raoord; 


Figure  22.  Forcing  a  32-bit  Access  Type 


dagraaa_par_*acond_d#lta  :  oonatant  :«  2 . 0**  (-6)  ; 

typa  dagraa*_par_aacond  la  dalta  dagroaa_j>ar_aaoond_dalta 

ranga  -(2. 0**9)  ..  (2 . 0**9) -dagraaa_por_aaaond_dalta; 

t or  dagraaa_par_aacond'  also  uaa  16; 

Figure  23.  Forcing  a  Fixed-Point  Representation  without  Using  'Small 
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SECTION  VI 


EVALUATION  OF  AN  ADA  COMPILER  AND 
ITS  USE  IN  THE  11TH  MISSILE  APPLICATION 

The  inability  of  Ihe  selected  Ada/1750A  compiler  ("Compiler  B")  to  correctly  compile  the  CAMP 
parts  and  11th  Missile  Application  code  caused  program  delays,  reduced  productivity,  and  ultimately, 
because  of  the  lack  of  adequate  work-arounds  for  some  of  the  compiler  errors,  prevented  hardware-in-the- 
loop  testing  of  the  Navigation  CSC. 

During  the  course  of  the  11th  Missile  Application  development,  many  compiler  errors  were  un¬ 
covered;  additionally,  a  substantial  number  of  deficiencies  in  the  run-time  performance  of  generated 
1750A  object  code  were  uncovered.  In  some  areas,  Ihe  compiler  functioned  well,  producing  efficient 
code  on  a  par  with  more  mature  Jovial  compilers,  but  in  other  cases  incorrect  or  inadequate  code  was 
produced. 

The  complicated  semantics  of  the  code  very  often  proved  to  be  too  much  for  the  compiler,  which, 
although  validated,  was  immature  in  the  more  advanced  areas  of  the  Ada  language.  For  this  reason,  much 
effort  was  expended  both  generating  Software  Problem  Reports  for  the  compiler  vendor,  and  devising 
work-arounds. 

After  compiler  updates  and  modifications  to  the  CAMP  code  produced  executable  software,  the 
execution  time  and  storage  efficiency  of  the  object  code  produced  by  the  compiler  were  not  acceptable  for 
real-time  embedded  (RTE)  applications.  Unfortunately,  the  most  powerful  Ada  features  (tasking, 
generics,  and  variant  records)  were  the  least  efficiently  implemented.  This  implies  that,  for  the  time 
being,  more  sophisticated  applications,  including  those  using  reusable  software,  will  experience  propor¬ 
tionally  greater  run-time  performance  degradation. 

I.  COMPILER  PROBLEMS  AND  SOLUTIONS 

The  Ada  compiler  selected  for  the  11th  Missile  Application  never  compiled  all  of  the  Ada  code  in  its 
original  form.  A  workable  load  module  could  only  be  generated  by  "manually  instantiating"  numerous 
generics,  manually  in-lining  some  subprograms,  and  by  combining  separate  compilation  units. 

a.  History  of  Compiler  Utilisation 

"Compiler  B"  was  initially  selected  for  the  11th  Missile  Application.  Benchmark  tests  of 
"Compiler  B"  showed  the  code  generated  by  it  to  be  as  efficient  as  that  produced  by  a  JOVIAL  compiler. 
However,  it  had  two  major  problems.  First,  it  was  not  validated  and  was  not  able  to  generate  valid  code 
for  the  very  first  1 1th  Missile  unit  test  attempted.  Second,  it  did  not  implement  extended-precision 
floating-point,  which  was  required  for  1 1th  Missile  navigation  and  Kalman  filtering  functions. 

For  these  reasons,  the  11th  Missile  team  switched  to  "Compiler  A"  in  November,  1986. 
"Compiler  A"  was  validated,  but  not  mature  enough  to  compile  the  CAMP  parts.  It  also  turned  out  to  be 
extremely  inefficient,  generating  object  code  modules  3  to  5  times  larger  than  those  produced  by 


61 


"Compiler  B".  "Compiler  A"  (indeed,  all  Ada/1750A  compilers  at  the  time)  limited  object  code  to  64K- 
words  instruction  space  plus  64K-words  data  space.  It  was  not  possible  to  fit  the  1 1th  Missile  code  into 
that  amount  of  memory  with  such  an  inefficient  compiler. 

When  it  became  apparent  that  there  would  be  no  quick  solutions  to  "Compiler  A’s"  problems 
(June,  1987),  the  1 1th  Missile  team  switched  back  to  "Compiler  B”.  By  this  time,  "Compiler  B”  had  been 
validated  and  extended-precision  floating-point  had  been  added.  The  compiler  was  still  more  efficient 
than  "Compiler  A".  Another  major  consideration  was  that  "Compiler  B’s"  vendor  provided  much  better 
(though  much  more  expensive)  maintenance  support. 

b.  Summary  of  Problem  Reports 

"Compiler  B"  was  still  not  a  mature  product,  however,  as  shown  both  by  the  number  of  problem 
reports  submitted  to  the  vendor  and  by  the  nature  of  the  reports.  Over  the  course  of  the  11th  Missile 
development,  98  test  cases  were  submitted  to  the  vendor  as  107  problem  reports  (some  were  submitted 
more  than  once). 

Table  27  summarizes  the  problem  reports  by  category.  "Other"  includes  library  errors,  evalua¬ 
tion  of  compound  boolean  expressions,  passing  parameters  to  subprograms,  code  optimizer  errors,  etc. 
Although  most  of  the  reports  involve  advanced  Ada  features  (e.g.,  tasking,  generics),  many  of  them  were 
mundane  (e.g.,  separate  compilation  of  non-generic  subunits,  boolean  expressions).  The  vendor’s  com¬ 
piler  fixes  would  sometimes  reopen  old  problems.  Sometimes,  modifications  would  cause  the  compiler  to 
fail  the  ACVC  test  suite.  In  short,  "Compiler  B"  was  not  a  mature,  reliable  product. 


TABLE  27.  PROBLEM  REPORTS  BY  CATEGORY,  COMPILER  B" 


Category 

Nuaber  of 

Problem* 

Canaria* 

52 

Ticking 

12 

Visibility  Aula* 

10 

Separate  Compilation  (non-genaria) 

6 

Dear  Error 

4 

Excessive  Storage 

3 

Other 

20 

The  frequency  of  problem  reports  did  not  decline  with  time.  Figure  24  plots  the  number  of 
problem  reports  submitted  each  month.  The  frequency  of  problem  reports  actually  increased  with  time, 
but  this  is  more  a  function  of  the  amount  of  effort  the  1 1th  Missile  team  put  into  testing  the  software  than 
the  maturity  of  the  compiler. 

Figure  24  shows  a  pair  of  early  problem  reports  submitted  before  the  project  switched  to 
"Compiler  A"  (November,  1986).  No  further  reports  were  submitted  until  the  project  began  to  consider 
switching  back  to  "Compiler  B".  From  April  through  August,  1987,  the  approach  was  to  test  a  new 
compiler  release,  find  the  problems,  submit  test  cases,  and  then  wait  for  the  next  release.  In  the  Fall  of 
1987,  the  strategy  was  switched  to  finding  work-arounds  to  allow  11th  Missile  unit  testing  to  proceed, 
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instead  of  waiting  for  the  next  compiler  delivery.  As  a  result,  the  problem  submittal  rate  went  up.  But, 
within  each  of  the  two  phases  (Apr- Aug  87  and  Sep  87- Apr  88),  there  is  no  clear  trend;  the  number  of 
problem  reports  neither  rose  nor  declined. 

Figure  25  shows  the  cumulative  number  of  reports  submitted,  including  those  re-opened,  and 
the  number  of  problems  fixed.  The  vertical  distance  between  the  lines  is  the  number  of  open  reports.  The 
horizontal  distance  is  the  average  time  required  to  fix  a  problem.  As  can  be  seen,  the  average  time  to  fix  a 
problem  increased  with  time. 

MDAC-STL  had  an  "on  call"  maintenance  contract  with  the  compiler  vendor.  This  is  a  stan¬ 
dard  contract  that  allowed  MDAC  to  consult  by  phone  and  to  submit  problem  reports.  The  vendor  sent 
one  or  more  Ada  system  updates,  as  required,  to  MDAC  between  official  releases.  The  vendor’s  response 
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-  Submitted/Reopened 

.  Closed 

Figure  25.  Cumulative  History  of  Problem  Reports,  "Compiler  B" 

to  problem  reports  was  excellent.  Nevertheless,  over  the  life  of  the  program,  the  average  time  to  fix  a 
problem  was  37  calendar  days  (including  week-ends  and  holidays).  This  shows  that,  until  Ada/1750A 
compilers  mature,  an  Ada  project  with  critical  schedule  deadlines  must  put  a  compiler  vendor  under  a 
special  contract  to  fix  problems  quickly. 
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c.  Some  Compiler  Problems  and  Work-Arounds 

Some  of  (he  problems  encountered  with  "Compiler  B"  and  work-arounds  for  them  are  explained 
in  the  following  paragraphs. 

( I )  fieri  erics 

A  major  and  recurring  problem  was  "Compiler  B’s"  inability  to  handle  complex  generics. 
Sometimes,  all  that  was  required  to  get  the  compiler  to  accept  a  generic  was  to  combine  separate  compila¬ 
tion  units.  That  is,  the  Ada  body  stubs  within  a  generic  unit’s  body  were  expanded  in  place  by  directly 
importing  the  required  code.  This  simplified  things  for  the  compiler  and  often  allowed  the  code  to  be 
compiled  without  errors,  although  there  were  some  disadvantages  to  this.  In  addition  to  the  time  and 
effort  required  to  reorganize  the  files,  the  physical  organization  of  the  software  was  disrupted,  making 
up-to-date  documentation  more  difficult  to  maintain  and  modifications  more  difficult  to  make.  Further¬ 
more,  the  simple  expedient  of  combining  separate  subunits  was  often  unsuccessful. 

When  combining  subunits  failed,  a  more  extreme  approach  was  to  replace  generic  instan¬ 
tiations  with  customized  "manual  instantiations"  of  the  associated  code.  This  involved  retrieving  the 
software  for  a  required  generic  and  manually  converting  it  to  a  non-generic.  The  code  created  was  then 
placed  into  the  software  in  place  of  the  instantiation.  Figures  26  and  27  give  an  example. 

In  many  cases,  manual  instantiation  was  not  a  trivial  process,  since  some  logical  implica¬ 
tions  of  a  generic  instantiation  are  difficult  or  impossible  to  duplicate.  For  example,  a  generic  instan¬ 
tiation  may  occur  anywhere  in  a  declarative  part  that  a  package,  task,  or  subprogram  specification  may 
occur.  Where  such  an  instantiation  occurs,  a  body  for  the  instantiated  unit  is  implicitly  created  and  the 
elements  of  the  unit  are  accessible  according  to  the  rules  of  Ada.  However,  when  the  unit  is  manually 
instantiated,  a  body  is  created,  and  that  body  cannot  necessarily  be  inserted  at  the  site  of  the  former 
instantiation  because  of  language  rules.  Since  the  manually  created  unit  body  of  the  former  generic  must 
usually  be  positioned  at  some  distance  from  the  manually  created  specification,  the  possibility  arises  that 
an  element  of  the  unit  will  be  referenced  prior  to  the  necessary  body  elaborations.  The  chance  that  such 
error  conditions  would  develop  made  the  manual  instantiation  of  generics  a  last  resort. 

Interestingly  though,  the  insertion  of  customized  code  in  place  of  generic  instantiations 
usually  brought  about  a  savings  in  object  code  size  and  in  operand  memory  utilization.  (This  is  explained 
fur  her  in  Section  VI.2.)  Indeed,  even  when  the  compiler  successfully  implemented  generics,  it  was  oc¬ 
casionally  necessary  to  use  manual  instantiation  to  conserve  storage  space. 
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with  Bua_T«ralnal« , 

BXM_Xntarf  «o«_Typ««  ; 
jwwria 

thii^ttzwintl  :  in  Bua_T*rminnl« .  twrmlnala; 

bu*_dalay  :  in  Standard .  duration; 

with  proaadura  Raoaiva__Maif aga 

(Maaaga  :  in  BIM_Intarf  aca_Typaa  .  input_>a>«aga_ptra)  ; 
paokaga  RT_BIM_Intarfaoa  la 

taak  tjrpa  BIM_Intar£acaa  ia 


•nd  BIM_Intarfaoaa; 
BtH_Zntar£aaa  :  BZM_Intarfaoaa; 
and  RT  BIX  Intar faoa; 


paokaga  body  RT_BIM_Intarfaaa  ia 
taak  body  BIM_Xntarfaaoa  la 


and  BIM_Intarf aca* ; 
and  RT  BIM  Intar faoa; 


with  RT_BIM_Xntarfaoa, 

Bua_Tamlnala  ; 
paokaga  body  Bnvironaant  la 

paokaga  Extamal_BIM  la  naw  RT_BXM_Xntarfaoa 

(thla_tarminal  ■>  Sua_?arminaXa  ■  Wav; 

buadalay  ■>  0.3; 

raoaivajaaaaaga  »>  Maaaaga_Managar  .Raoalva^Naaaaga)  ; 

and  Environannt; 


Figure  26.  Code  Before  Manual  Instantiation 


(2)  Separate  Subunits 

Often,  the  compiler  was  unable  to  handle  deeply  nested  separate  compilations  of  unit 
bodies,  evcu  those  which  were  not  generic.  This  was  generally  fixed  by  combining  separate  subunits  into 
one  file  as  described  above. 

Figures  29  through  32  give  a  graphical  representation  of  the  effect  of  manual  instantiations 
and  separate  body  combination  on  the  Guid.Computer  software.  Figure  28  explains  the  symbols  used  in 
the  next  four  figures.  The  first  two  figures  depict  the  baseline  Guid_Computer  procedure  as  well  as  the 
Guidance_Operations  package  it  contains.  The  third  and  fourth  figures  show  the  same  two  units  after 
being  modified  to  manually  instantiate  generics  and  combine  separate  bodies. 
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—  Oanarlc  RT_BXM_Intarfaca  packaga  no  longar  naadad. 

with  Bua_Tarminala, 

BXM_Xntarf aaa_Typaa ; 
pukaga  body  Environment  la 

package  External_BXM  la 

—  —  Object  daalaratlona  and  aubprograa  ronaminga  uaad  In  plaea  of  tha 

—  —  ganarla  actual  parameter* . 

thia_tarmlnal  :  Bua_Tarralnala .  tarainala  :»  Bua_Tarmlnala  . Mav; 

bua_delay  :  Standard. Duration  :»  0.3; 

procadura  Raoalva_Maaaaga  (Manage  :  In  BIM_Intorfaoa_Typaa .  input_Maaaga_ptra) 
ranaaaa  Maaaaga_Hanagar .  Racalva_Maaaaga; 

taak  typo  BIM_Intarfaoaa  la  —  Coda  dlractly  Imported  from  tha 

--  packaga  apacifloatlon  of  tha 

—  —  —  ...  —  ganarlc  packaga  RX_BXM_Xntarf aoa . 

and  BIM_Xnterfacea; 

BIM_Interface  ;  BIM_Intarfaoaa; 
and  External  BXM; 


packaga  body  Bxtarnal  BXM  la  --  Body  craatad  to  hold  body  coda  of  tha 

—  ganarla. 

taak  body  BXM_Xntarfaaaa  la  —  Coda  dlractly  iaported  froa  tha 

—  body  of  tha  ganarla  packaga 

. -  ...  —  kTBXMXntarfaoa. 

and  BIM_Xntarf acaa ; 

and  External__BIM; 

and  Environment; 


Figure  27.  Code  After  Manual  Instantiation 
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Table  28  shows  the  dramatic  reduction  in  the  use  of  generics  due  to  manual  instantiations. 
Table  29  shows  that  the  number  of  files  compiled  also  dropped  dramatically  as  separate  subunits  were 
combined  directly  into  their  parent  units. 

(3)  Parameter  Passing 

Occasionally,  even  a  simple  parameter  pass  would  not  work.  The  solution  to  this  problem, 
where  feasible,  was  to  manually  in-line  the  code  at  the  site  of  invocation.  Figures  33  and  34  show  an 
example  of  how  this  was  done.  Note  that  in  the  example,  the  names  of  the  actual  parameters  used  in  the 
procedure  call  matched  the  names  of  the  formal  parameters.  This  eliminated  the  need  to  rename  objects. 

(4)  Machine  Code  Patches 

Small  problems  in  code  generation,  such  as  the  use  of  an  incorrect  assembly  language 
instruction,  were  sometimes  solved  by  directly  modifying  the  machine  code  in  the  load  module.  For 
example,  a  failure  of  the  hardware-in-the-loop  test  of  the  Guid.Computer  was  directly  attributable  to  the 
compiler’s  incorrect  choice  of  shift  instructions:  an  arithmetic  shift  had  been  used  in  place  of  a  logical 
shift.  This  problem  was  corrected  by  altering  the  instruction  word,  a  modification  which  permitted  the 
test  to  run  to  completion  without  error. 

(5)  Memory  Utilization 

Late  in  the  project,  the  compiler  was  found  to  make  extremely  inefficient  use  of  temporary 
operand  storage  space.  Because  of  this,  the  1 ’  th  Missile  Nav_Compuler  Software,  which  was  larger  than 
the  Guid.Computer,  could  not  initially  be  linked.  When  the  static  operand  memory  usage  was  reduced  by 
software  modifications,  the  successfully  linked  code  still  failed  to  run  because  of  inefficiencies  in  the  use 
of  dynamic  operand  memory  This  latter  problem  was  caused,  not  by  the  explicit  use  of  dynamic  memuvy 
by  the  software,  but  by  implicit  uses  of  the  heap  by  the  generated  object  code.  Also,  the  dynamic  memory 
dedicated  to  the  run-time  stack  was  overused  by  inefficient  allocations  of  temporary  variable  space.  As  a 
result,  the  working  storage  requirements  of  a  subprogram  or  task  were  almost  always  more  than  had  been 
anticipated  during  the  design  of  the  software. 

One  compiler-related  space  inefficiency,  which  was  partially  corrected  by  the  vendor,  was 
the  failure  to  make  thrifty  use  of  temporary  space.  A  subprogram,  for  example,  required  not  only  the 
operand  space  implied  by  the  subprogram’s  local  variables,  but  also  required  temporary  space  for  each 
operator  result.  Because  the  1 1th  Missile  incorporated  large  Kalman  filter  matrices,  this  was  a  serious 
deficiency  which  quickly  caused  the  Nav_Compu'er  to  run  out  of  operand  space.  The  stack  simply  could 
not  be  made  large  enough  to  accommodate  the  inefficiency. 

As  a  temporary  solution  to  the  problem,  expressions  containing  operators  with  large  results 
were  sometimes  placed  within  local  procedures;  Figure  35  shows  an  example  of  this.  To  a  large  extent, 
this  limited  the  effect  of  the  problem  since  the  space  set  aside  for  the  local  procedures  was  immediately 
reclaimed  after  exiting  those  procedures. 
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Figure  29.  Baseline  Guid_Computer  Procedure 
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Package  Guidance.Operations 
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Procedure  Guid_Computer  (Main) 


Figure  31.  Modified  Guid_Computer  Procedure 
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Package  Guidance_Operations 


Figure  32.  Modified  Guidance_Operations  Package 
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TABLE  28.  USE  OF  GENERICS  IN  BASELINE  AND  MODIFIED  SOFTWARE 


Excluding  Unchecked 
Conversion/Deallocation 

Including  Unchecked 
Conversion/Deallocation 

Baseline 

Modified 

Baseline 

Modified 

Guid_Computer 

Distinct  Generics 

33 

9 

35 

11 

Nav_Computer 

Distinct  Generics 

73 

49 

75 

52 

Raw  Total 

Distinct  Generics 

106 

00 

110 

63 

Guid_Computer 

Instantiations 

49 

16 

74 

43 

Nav_Computer 

Instantiations 

126 

84 

200 

149 

Total 

Instantiations 

175 

100 

274 

192 

TABLE  29.  SEPARATE  SUBUNITS  AND  FILES  COMPILED 


Guid_Computer  Files 
Nav_Computer  Files 

Baseline 

89 

213 

Modified 

59 
’  177 

Total  Files 

306 

233 

Nav_Computer  Separate 
Subunits 

128 

98 

Guid_Computer  Separate 
Subunits 

37 

20 

Total  Separate  Subunits 

165 

118 

Later,  the  compiler  vendor  implemented  a  more  efficient  allocation  scheme  for  temporary 
variables  and  the  need  for  enclosing  procedures  was  reduced.  However,  certain  expressions,  particularly 
very  long  or  very  complex  expressions  in  the  right-hand  sides  of  assignment  statements,  still  made  exces¬ 
sive  use  of  operand  space.  This  problem  proved  to  be  far  more  tractable,  and  was  remedied  by  breaking 
up  long  expressions  into  intermediate  sub-expressions  and  using  multiple  assignment  statements. 

A  second  and  more  serious  problem  was  the  failure  to  reuse  temporary  operand  space  in 
the  compiler's  implementation  of  generics.  While  return  values  for  ordinary  operators  and  functions  were 
placed  on  the  stack  and  subsequently  reclaimed,  the  return  values  of  generic  functions  (and  functions 
returning  types  obtained  from  generic  instantiations)  were  placed  in  space  dynamically  allocated  from 
heap.  The  heap  space  was  never  reclaimed  and  the  heap  was  quickly  exhausted.  The  primary  work¬ 
around  for  this  was  the  manual  instantiation  of  offending  objects,  types,  and  operators.  Nevertheless,  the 
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pteocduc*  Parfona_riight_Control_Op*rationa 


(Bank_Rata_Llm_Orar_lC_Bac 
rint_Pui 
K  ~ 

Phi_C 
Roll_Angla 
Phi_CLTD 
Bank  Xrcor 


GOT .  Radi an«_rP ; 
SOT. Radian*  IT; 


In  ODT.RadianaJTP; 
in  BOOLXW; 

in  ODZ.Singl*_Praol*ion_rieat; 
in  9DI.Radiana_PV; 
in  GDI. kadi ana_FP; 
in  out  ODT.kadian*_rP; 
out  ODT.Radian*_IT; 
out  GDT. Volta)  ia 


bagin  —  Pcr;orm_riight_Control_Oparation» 


Phl_CLID  :»  BankQnd_Abaoluta_Limitar .  Limit  (Signal  »>  Phi_C)  ; 


PhiCLTD_Upp*r_Low*r_Limitar .  Updat  a_L  imi  t  a 

(Rw_Dpptl_Uait  ■>  Phi_CLTDP  +  Bank_Rata_Llm_OTar_lB_8aa, 
Maw  Lowar  Limit  ■>  Phi  CLTDP  -  Bank  Rata  Llm  Ovar  1C  Baa) ; 


damage  caused  by  the  problem  was  so  extensive  that  several  unit  tests  could  not  realistically  be  fixed. 
Completion  of  those  tests  was  forced  to  await  compiler  modifications  which  the  vendor  made  at  the 
suggestion  of  the  1 1th  Missile  team. 
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b*gln  --  ProcMtor 

—  Oth«r  itat«Mnt 
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—  Othar  atataMnta  ,  .  . 
and  Procaaaor; 

Figure  34.  Section  of  Code  After  Manual  In-lining 

2.  COMPILER  INEFFICIENCY 

The  Ada/1750A  cross-compiler.  "Compiler  B  ",  used  on  1 1th  Missile  was  (as  of  May,  1988)  in  need 
of  much  improvement.  Certain  Ada  constructs,  especially  the  more  powerful  ones,  were  not  implemented 
efficiently.  Other  constructs  seemed  to  incorporate  a  good  deal  of  optimization,  yet  the  result  was  far 
from  ideal.  It  is  clear  that  the  compiler  developers  are  faced  with  a  very  challenging  task. 

a.  Tasking 

The  most  costly  throughput  problem  was  the  compiler’s  implementation  of  Ada  tasking.  In  the 
Guid_Computer,  75%  of  processor  throughput  is  expended  in  task  rendezvous  overhead  while  an  ad¬ 
ditional  12%  of  throughput  is  expended  for  the  remainder  of  the  program.  Although  this  processor-lime 
consumption  still  allows  llie  Guid_Compuler  to  function  within  its  real-time  performance  requirements, 
the  high  overhead  of  task  rendezvous  is  serious.  In  the  Nav_Computer,  where  tasking  overhead  is  138% 
of  processor  throughput,  the  real-time  performance  requirements  are  well  out  of  reach. 
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proeadura  Ixupl*  1*  —  Spaa*  wasting. 
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bagln 
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Figure  35.  Saving  Stack  Space  Using  Enclosing  Procedures 


Hie  compiler  vendor  blames  this  poor  tasking  run-time  performance  on  Ada  requirements  for 
exception  propagation.  The  language  rules  require  that  an  exception  occurring  in  the  "do"  clause  of  an 
Ada  rendezvous  be  propagated  to  both  tasks.  The  set-up  for  these  exception  contingencies  is  non-trivial 
and  constitutes  a  large  part  of  the  excessive  task  rendezvous  overhead. 

Some  of  the  throughput  expense  of  tasking  can  be  reclaimed  by  making  careful  selections  of  the 
kinds  of  tasking  facilities  used.  For  example,  passing  parameters  to  task  entries  was  found  to  be  expen¬ 
sive,  as  was  the  use  of  many-branched  select  statements  and  the  use  of  guards  before  accept  statements. 
Benchmark  data  indicates  that  overhead  times  grow  quickly  and  proportionally  with  the  number  of  accept 
statements  used.  In  particular,  guarded  accept  statements  caused  overhead  times  to  grow;  a  greater  time 
expense  was  incurred  when  the  guards  evaluated  true.  Parameter  passing  also  caused  a  large  increase  in 
throughput  consumption  that  was  proportional  to  the  number  and  kinds  of  parameters  used.  By  minimiz¬ 
ing  parameter  passing  and  the  use  of  guards,  a  more  reasonable  execution  rate  could  be  obtained. 

b.  (Jen  erics 

While  tasking  proved  to  be  the  major  inefficiency  in  throughput  consumption,  the  use  of 
generics  was  also  very  costly.  As  previously  discussed,  the  use  of  heap  space  by  generics  wasted  operand 
memory.  Moreover,  throughput  was  adversely  affected  by  generic  subprograms  which  carried  a  much 
greater  run-time  cost  than  their  non-generic  counterparts.  Also,  surprisingly,  even  instruction  memory 
suffered  from  the  use  of  generics. 

"Compiler  B"  uses  a  single-body  implementation  of  generics.  One  reentrant  object  code  body 
is  created  and  used  for  all  instantiations  of  the  generic.  The  idea  was  to  save  memory  at  the  expense  of 
throughput,  which  would  be  expected  to  rise  for  three  reasons:  use  of  the  heap,  worst-case  assumptions 
for  generic  types,  and  translation  between  actual  and  formal  types. 

Generics  had  to  use  heap  for  any  object  whose  size  was  not  defined  (e.g.,  an  object  whose 
generic  formal  type  was  private,  or  an  unconstrained  array,  or  an  array  whose  index  type  was  also  a 
generic  parameter).  Although  once  the  compiler  had  been  fixed,  space  allocated  for  these  objects  was 
reclaimed  when  it  is  no  longer  necessary,  the  deallocation  scheme  inevitably  fragmented  the  heap.  Since 
real-time  embedded  systems  can  neither  afford  to  perform  extensive  garbage  collection  nor  allow  wasted 
space,  the  use  of  generics  was  severely  limited. 

A  small  execution  time  cost  was  the  assumption  of  "worst-case"  actual  types.  For  example,  if  a 
generic  formal  parameter  was  floating  point,  all  operations  on  that  type  had  to  be  implemented  as  ex¬ 
tended  floating  point  instructions,  just  in  case  the  generic  would  be  instantiated  with  an  extended-float 
actual  parameter. 

With  the  "single-body"  implementation,  each  instantiation  of  a  generic  unit  results  in  the  crea¬ 
tion  of  a  unique  interface  to  the  single  body  of  object  code.  This  interface  translates  from  the  actual  type 
to  the  underlying  implementation  before  invoking  the  body,  and  reverses  the  translation  after  the  body 
Completes.  For  example,  the  interface  code  might  convert  an  input  from  float  to  extended-float.  It  was 
expected  that  this  interface  code  would  take  additional  execution  time. 


78 


It  was  also  expected  (and  stated  in  the  literature  of  the  compiler  vendor)  that  the  single-body 
implementation  of  generics  would  result  in  an  over-alt  savings  in  instruction  memory.  This  turned  out  not 
to  be  the  case  because  the  customized  code  created  at  each  instantiation  more  than  outweighed  the  space 
savings  of  the  single-body  method.  For  example,  by  manually  instantiating  the  Kalman  filter  generics 
used  by  Nav_Computer,  a  total  of  1877  words  of  instruction  memory  were  saved.  The  savings  obtained 
was  not  expected,  since  the  Kalman_Filter  made  use  of  multiple  instantiations  of  the  same  generics, 
exactly  the  circumstance  under  which  the  single-body  method  should  have  performed  best.  The  major 
reason  for  this  apparent  paradox  is  the  small  size  of  the  CAMP  parts;  as  a  result,  the  interface  code  was 
larger  (sometimes  several  times  larger)  than  the  body  of  the  generic. 

The  single-body  method  could  be  used  in  some  cases  to  reduce  memory  usage.  The  compiler 
vendor  needs  to  provide  the  user  with  the  option  to  specify  either  multiple-  or  single-body  generics.  This 
could  be  done  by  implementing  PRAGMA  Optimize  or  PRAGMA  Inline. 

c.  Temporary  Data  Space 

In  the  absence  of  a  global  optimizer,  exception  handling  and  constraint  checking  mandate  the 
creation  of  a  temporary  object  to  store  the  value  of  the  right-hand  side  of  an  assignment  statement.  (This 
temporary  object  may  be  a  large  data  structure.)  If  an  exception  occurs  while  computing  the  right-hand 
side,  all  elements  of  the  left-hand  side  must  still  be  intact.  Also,  the  results  must  be  checked  for  confor¬ 
mance  to  type  constraints  prior  to  assignment  to  the  object  on  the  left-hand  side.  Either  rule  requires  a 
temporary  object. 

Therefore,  the  use  of  large  aggregates  and  functions  returning  large  data  structures  wasted 
operand  space.  Language  constructs  of  this  kind  were  originally  used  because  of  the  readability  and 
naturalness  of  expression  that  they  afford.  For  example,  under  the  object-oriented  design  paradigm,  a 
package  body  that  contains  a  large  matrix  would  permit  this  matrix  to  be  read  only  via  a  function  call  that 
returns  the  matrix.  Because  of  Ada  language  rules,  the  compiler  creates  intermediate  temporary  storage 
for  the  result  of  the  function  at  invocation.  The  necessity  for  this  temporary  space  makes  this  construct 
very  inefficient,  although  it  is  also  quite  desirable. 

Sufficiently  comprehensive  implementations  of  PRAGMAS  Inline  and  Suppress  would 
eliminate  most  of  the  space  inefficiency  in  this  case.  Specifically,  PRAGMA  Suppress  could  be  used  to 
eliminate  much  of  the  need  for  temporary  objects  returned  from  function  calls.  PRAGMA  Inline  would, 
in  fact,  remove  the  function  call  entirely  but,  without  PRAGMA  Suppress,  the  Ada  language  rules  would 
still  require  an  intermediate  temporary  object. 

Space  problems  excusable  by  Ada  language  requirements  were  often  rectified  by  altering 
baseline  code.  These  corrections  were  not  considered  work-arounds,  therefore,  but  permanent  changes  to 
the  software  baseline. 
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d.  Other  Causes  of  Inefficiency 

The  absence  of  PRAGMA  Inline  was  often  significant  to  the  11th  Missile  project.  In  many 
instances,  the  pragma  could  have  been  used  to  improve  efficiency.  For  example,  the  readability  of  long 
algorithms  was  enhanced  by  factoring  the  Ada  code  into  groups  of  subprograms.  Also,  because  of  object- 
oriented  design,  objects  were  hidden  in  package  bodies  and  had  to  be  accessed  via  function  calls.  Unfor¬ 
tunately,  without  PRAGMA  Inline,  a  price  was  paid  in  terms  of  throughput,  since  overhead  was  intro¬ 
duced  at  the  site  of  each  subprogram  call. 

Variant  records  were  costly  since  they  required  the  compiler  to  generate  code  for  storing  them, 
comparing  them,  and  altering  discriminants.  Unconstrained  arrays  contributed  to  heap  management 
problems  since  space  for  them  was  allocated  dynamically.  The  implementation  of  these  two  types  of 
objects  implied  an  unacceptably  sophisticated  use  of  memory  for  RTE  software. 

Finally,  an  important  waste  of  memory  space  was  the  inclusion  of  unnecessary  object  code  in 
load  modules.  The  compiler  used  by  the  11th  Missile  inserted  all  code  of  a  required  library  unit  in  the 
program  load  module,  even  if  only  a  part  of  the  code  was  actually  referenced.  Such  a  waste  of  instruction 
space  is  intolerable  for  any  real-time  embedded  application  using  the  CAMP  parts  since  many  of  them 
consist  of  large  groups  of  generics  bundled  together  into  a  package.  These  packages  had  to  be  modified 
and  recompiled  to  eliminate  unnecessary  code,  although  a  more  sophisticated  compiler/linker  would 
eliminate  the  need  to  do  this.  For  example,  a  compiler  could  separate  the  object  code  of  subunits  into 
separate  object  modules.  A  linker  could  then  perform  a  module  reference  analysis  to  determine  which 
modules  could  safely  be  excluded  from  a  link. 

The  problems  described  here  are  particularly  acute  for  real-time  embedded  code.  Some  would 
not  be  considered  problems  in  general  applications.  For  example,  the  VAX  Ada  compiler  is  generally 
regarded  as  excellent,  even  though  it  also  includes  unreferenced  code.  This  is  because  generally  a  VAX 
is  installed  with  megabytes  of  memory,  compared  to  128K  words  of  memory  for  the  11th  Missile  Ap¬ 
plication. 

e.  Are  These  Compiler  Problems? 

Some  of  the  inefficiencies  discussed  above  are  arguably  language  problems  rather  than  com¬ 
piler  problems.  This  is  particularly  true  of  task  rendezvous  times  and  the  requirements  for  temporary 
storage  of  intermediate  results. 

There  has  been  considerable  discussion  within  the  Ada  community  as  to  whether  or  not  an 
efficient  implementation  of  the  general  Ada  task  rendezvous  is  possible.  It  is  certainly  not  possible 
without  some  sort  of  global  optimizer.  Similarly,  the  temporary  space  allocation  problem  can  be  solved 
only  by  a  global  optimizer  that  knows  if  there  is  an  exception  handler  that  will  require  the  original  value 
of  the  left  hand  side  of  the  assignment.  Discussions  with  "Compiler  B’s"  vendor  indicate  that  such  an 
optimizer  is  years  in  the  future. 

Many  of  the  problems  appear  to  be  a  result  of  the  complexity  of  Ada.  At  least  in  the  short  term, 
the  complex  rules  imposed  by  Ada  evidently  leave  the  compiler  implementor  with  quite  a  chore  in  simply 


80 


achieving  conformance.  Because  of  this,  and  because  the  Ada  Compiler  Validation  Capability  (ACVC) 
does  not  check  for  it,  efficiency  is  often  sacrificed  to  achieve  validation.  The  complexity  issue  has  often 
been  raised  as  a  criticism  of  Ada  and,  at  least  for  the  time  being,  it  appears  to  be  a  significant  factor  in  the 
industry's  effort  to  develop  efficient  and  effective  RTE  Ada  compilers. 
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SECTION  VII 


CONCLUSIONS  AND  RECOMMENDATIONS 

1.  CONCLUSIONS 

•  The  11th  Missile  development  demonstrated  that  a  productivity  improvement  as  high  as  15%  is 
possible  for  a  navigation  &  guidance  application  using  the  CAMP  parts,  and  that  a  productivity 
improvement  as  high  as  28%  is  possible  for  this  type  of  application  using  both  the  CAMP  parts 
composition  system  Kalman  Filter  Constructor  and  the  CAMP  parts. 

•  The  full  productivity  improvements  from  using  a  PCS,  or  even  the  parts,  will  not  be  realized  until 
MIL-STD-1750A-targeted  Ada  compilers  mature. 

•  The  MIL-STD-l750A-targeted  Ada  compilers  examined  by  the  11th  Missile  team  are  currently 
(May,  1988)  inadequate  for  the  following  reasons: 

-  They  do  hot  handle  complicated  generics.  The  CAMP  parts  utilize  the  most  advanced 
generic  features  of  Ada.  The  three  validated  Ada/1750A  compilers  tested  by  MDAC-STL 
either  did  not  compile,  or  did  not  correctly  execute,  the  CAMP  parts. 

-  Generic  instantiations  are  inefficient.  "Compiler  B"  used  a  single-body  approach,  which  has 
significant  execution-time  and  memory  penalties.  "Compiler  A"  used  a  multiple-body  ap¬ 
proach,  even  if  the  underlying  base  types  are  identical. 

-  PRAGMA  Inline  is  not  fully  implemented.  "Compiler  B”  did  not  implement  this  pragma  at 
all.  Neither  "Compiler  B"  nor  "Compiler  A"  in-lined  instantiations  of  generics.  Since  many 
of  the  parts  are  very  small,  there  is  a  significant  usage  penalty  if  instantiations  of  generics 
cannot  be  put  in-line. 

-  Task  rendezvous  are  inefficient.  Over  75%  of  the  Guid  computer’s  and  over  135%  of  the 
Navigation  computer's  throughput  was  required  for  task  rendezvous. 

•  Ada  is  an  effective  language  for  real-time  embedded  software,  provided  that  the  optional  ("Chapter 
13")  features  of  the  language  are  implemented. 

•  The  PCS  Kalman  Filler  Constructor  did  not  generate  code  suitable  for  use  in  the  11th  Missile 
Application,  ihe  full-matrix  code  would  have  been  loo  slow,  while  the  sparse-matrix  code  ex¬ 
ceeded  the  instruction  memory  limit. 
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•  The  PCS  or  the  CAMP  parts  need  to  be  extended  into  new  areas,  particularly: 

•  Floating-point  operators  (the  strong  typing  philosophy  embodied  by  the  CAMP  parts  means 
that  many  such  operators  arc  needed  for  an  application) 

-  Records  and  representation  specifications  for  I/O  ports  or  messages,  and  code  to  read 
from/write  to  those  records 

-  Code  to  sequence  navigation  functions 

-  Code  to  sequence  Kalman  functions 

•  Parts  in  the  following  areas  need  to  be  modified  or  added: 

-  Coordinate  Vector  Matrix  Algebra 

-  Wander  Azimuth  Navigation 

-  Waypoint  Steering 

-  Kalman  Filter 

-  Signal  Processing 

•  Geometric  Operations 

-  WGS 

-  Flat-earth  Navigation 

2.  RECOMMENDATIONS 

This  Section  recommends  modifications  to  the  CAMP  parts,  PCS,  and  Ada. 
a.  Modifications  to  Parts 

•  Revisions  to  Coordinate_Vector_Matrix_Algebra  (CVMA) 

-  Change  Matrix_Operations  so  that  the  two  axes  of  type  matrices  can  be  different  (see  Figure 
36).  The  most  common  use  for  the  3-by-3  matrices  handled  by  CVMA  is  coordinate  trans¬ 
formations.  The  old  coordinate  frame  indexes  the  columns  and  the  new  frame  indexes  the 
rows. 

-  Make  similar  modifications  to  Matrix_Scalar_Operalions,  Malrix_Vector_MuItiply  and 
Matrix_Matrix_Multiply  (see  Figures  37,  38,  and  39). 

-  Add  parts  to  transpose  a  matrix  and  to  multiply  by  the  transpose  of  a  matrix. 

•  Drop  Compute_Latitude_Using_Arctangent,  Compute_Longilude,  and  Compute_Wander_ 
Azimuth_Angle  from  Wander_Azimulh_Navigation_Parls  (WANav).  These  parts  all  use  single- 
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Current 


ganarlo 

typa  Axaa  la  (<>) ; 

typa  BlaaMnta  la  dlglta  <>; 
paakaga  Matrlx_Oparatlona  la 

typa  Matrlaaa  la  array  (Axaa,  Axaa)  of  BlaaMnta ; 


and  Mat rlx_Oparat Iona ; 


Recommended 


ganarlo 

typa  Row_Axaa  la  «» ; 
typa  Col_Axaa  la  (<>) ; 
typa  BlaaMnta  la  dlglta  <>; 
paokaga  Matrlx_Oparatlona  la 

typa  Matrlaaa  la  array  (Ao«_Axaa,  Col_Axaa)  of  BlaaMnta ; 


and  Matrlx_Oparatlona; 


Figure  36.  Recommended  Change  to  Matrix_Operations 

parameter  arctangents.  (Versions  using  two-parameter  arctangents  are  also  in  WANav.)  The  lon¬ 
gitude  and  wander-azimuth  parts  give  incorrect  answers  whenever  the  correct  answer  is  in  the 
second  or  third  quadrant.  In  theory,  the  latitude  part  is  correct,  but  all  single-parameter  arctangent 
functions  lose  accuracy  near  the  poles.  No  military  system  can  live  with  such  restrictions;  there¬ 
fore,  these  parts  should  be  dropped. 

•  Change  Crosstrack_and_Heading_Error_Operations  (part  of  Waypoinl_Steering)  to  use  two- 
parameter  arctangent  functions  instead  of  single-parameter  arctangents.  The  part  is  written  with  no 
assumptions  on  the  range  of  the  heading  error,  so,  to  be  consistent,  it  should  use  full-range  arctan¬ 
gent  functions. 

•  Investigate  every  instance  of  a  single-parameter  arctangent  in  the  parts.  In  each  case,  determine 
whether  or  not  it  should  be  changed  to  a  two-parameter  arctangent,  or  if  an  equivalent  part  that  uses 
a  two-parameter  arctangent  should  be  added. 

•  Changes  to  Kalman  filter  parts 

-  Add  a  measurement  reasonableness  test  that  implements  the  following: 

Reasonable  :=y2  <  MOiPh1  +  r) 
where  Reasonable  =  true  if  measurement  is  acceptable 
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Current 

ganario 

typa  Axaa  la  (<>) ; 

typa  Elaaiantal  la  diglta  <>; 
typa  Blananta2  la  diglta  <>; 
typa  Soalara  la  diglta  <>; 

typa  Matrloaal  la  array  (Xxaa,  Axaa)  of  Elaaiantal; 
typa  Natrloaa2  la  array  (Axaa,  Axaa)  of  Elaa»nta2; 
with  function  (Laft  :  Elaaiantal; 

Right  ;  Soalara)  raturn  Elaaaanta2  la  <>; 
with  function  "/"  (Laft  :  Elaaianta2 ; 

Right  :  Soalara)  raturn  ElaaMntal  la  <>; 
paokaga  Matrlx_Soalar_Oparatlona  la 

function  (Matrix  ;  Matrloaal; 

Multlpllar  :  Soalara)  raturn  Matrlcaa2; 

function  "/"  (Matrix  ;  Matrioaa2; 

Diviaor  ;  Soalara)  return  Matrloaal; 

and  Matrlx_3calar_0peratloie; 


Recommended 

ganarlo 

typa  Row_Axea  la  (<>) ; 
typa  Col_Axaa  la  «»  ; 
typa  Elaawntal  la  diglta  <>; 
typa  ElaaMnta2  la  diglta  <>; 
typa  Soalara  la  diglta  <>; 

typa  Matrloaal  la  array  (Row_Axaa,  Col_Axaa)  of  ElaMantal; 
typa  Matrlaea2  la  array  (Row_Axaa,  Col_Axaa)  of  ElaNenta2; 
with  funatlon  (Loft  ;  Elaaiantal; 

Right  ;  Soalara)  return  Elaaanta2  la  <>; 
with  funatlon  " /"  (Left  :  Elanwnta2; 

Right  :  Soalara)  raturn  Elaaiantal  la  <>; 
paokaga  Matrlx_Scalar_Oparatlona  la 

funatlon  (Matrix  :  Matrloaal; 

Multlpllar  :  Soalara)  raturn  Matrloaa2; 

funatlon  (Matrix  ;  Matrloaa2; 

Dlvlaer  :  Soalara)  raturn  Matrloaal; 


and  Matrix_Soalar_Oparationa; 


Figure  37.  Recommended  Change  to  Malrix_Scalar_Operalions 


y  =  i"'  element  of  the  measurement  vector.  Y 
M  =  tolerance 

h  =  i"1  row  of  the  measurement  sensitivity  matrix,  H 
P  =  system  covariance  matrix 

r  =  i"'  diagonal  element  of  the  measurement  covariance  matrix,  R 
Two  versions  will  be  needed,  one  each  for  compact  and  complicated  representations  of  H. 

•  Add  Compute_KaIman_Gain  parts  that  take  advantage  of  intermediate  products  computed  in 
the  reasonableness  test.  Both  the  reasonableness  test  and  Compute_Kalman_Gain  compute 
liPh1  +  r.  In  addition,  Compule_Kalman_Gain  computes  PhT,  which  is  an  intermediate  result 
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Current 

ganwrlo 

typ«  kx»t  ia  (O)  ; 

typa  Input_Vaotor_»l»M«nt«  la  digit  a  <>; 
typa  Output_V«otor_El«Mnta  la  digit  a  O; 
typa  Matrlx_Xlaawnta  la  dlglta  <>; 

typa  Input_Vaetera  ia  array  (lx*a)  of  Input_Vaotor_Ela«aanta  ; 

typa  Output_Vactora  ia  array  (Axaa)  of  Output_Vaotor_SlaaMnta; 

typa  Matrloaa  ia  array  (Azaa,  Ixaa)  of  Matrlx_llaaanta; 

with  function  *•*  (Laft  :  Matrlx_Elaatanta; 

Right  :  Input_Vacto<:_Ziaawnta) 
rat  urn  Output_Vaotor_Ela>anta  la  <>; 
funatlon  Matrix_Vaotor_Multiply 
(Matrix  :  Matrloaa; 

Vaotor  :  Input_Vaotora)  ratum  Output_Vaotora; 


Recommended 

ganario 

typa  hxaal  ia  (<>) ; 

typa  Axaa2  la  (<>) ; 

typa  Input_Vactor_ElaMnta  ia  dlglta  O; 
typa  Output_yactor_Elaaanta  ia  dlglta  O; 
typa  Matrix_Elaaianta  la  dlglta  <>; 

typa  Xnput_yaatora  ia  array  (Axaa2)  of  Xnput_Vaotor_Elaaanta ; 

typo  Output_Vaotora  ia  array  (Axaal)  of  Output_Vaotor JElaawnta ; 

typa  Matrloaa  ia  array  (Axaal,  Jtxaa2)  of  Matrlx_ElaaMnta; 

with  funatlon  (Laft  ;  Matrlx_Elaaanta; 

Right  :  Xnput_Vaotor_Elaawnta) 
ratum  Output_VaatorJUaawnta  la  <>; 
function  Matrix_Vaotor_Multlply 
(Matrix  :  Matrloaa; 

Vaotor  ;  Xnput_Vactora)  ratum  Output_Vaatora ; 


Figure  38.  Recommended  Change  to  Matrix_Veclor_Multiply 


of  the  first  compulation.  Versions  of  Compute_Kalman_Gain  should  be  written  that  make 
use  of  these  intermediate  products  from  the  reasonableness  tests. 

•  Add  simultaneous  update  parts.  The  current  parts  sequentially  update  the  state  and 
covariance,  using  one  measurement  element  and  one  row  of  H  at  a  time.  A  simultaneous  part 
would  update  all  elements/rows  at  once.  A  part  to  invert  symmetric  matrices  will  need  to  be 
added  to  General_Vector_Matrix_Algebra  to  support  this. 

-  Revise  the  higher-level  Kalman  parts  (Sequentia!ly_Update_Covariance_Matrix_and_Stale_ 
Vector  and  Ka!man_Update)  to  take  (he  procedures  they  will  instantiate  as  arguments.  This 
gives  the  user  the  option  of  specifying  which  procedure  to  use  for  Compute_Kalman_Gain, 
and  Update_P. 

•  Signal_Processing  Changes 

-  Add  a  first-order  filter  that  allows  the  user  to  specify  the  initial  values  of  both  the  "previous 
input”  and  the  "previous  output"  (these  are  stored  in  the  filter  software). 
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Current 

gonorie 

typw  Xxas  la  (<>) ; 

typa  Laft_Clananta  la  digit*  <>; 
typa  Right_Elowionta  la  digit*  <>; 
typa  Raault_Eloa*nta  la  dlglta  <>; 

typa  Laft_Matrloaa  la  array  (Jtxaa,  Mat)  of  Laft_Blaatanta; 

typa  Rlght_Matrlca»  la  array  (Axoa,  Axaa)  of  Right_Elw»onta ; 

typa  Xaault_Hatrioaa  la  array  (Axoa,  Axaa)  of  Ra*ult_Elta*nta; 

with  function  (Loft  :  Loft_ElaoMnta; 

Right  :  Right_Elaaonta)  raturn  Ro*ult_XlaaMnt*  la  <>; 
function  Matrlx_Matrix_Multlply 

(Matrlxl  :  Laft_Matrloaa ; 

Mat r 1x2  :  Rlght_Katriaaa)  raturn  Raault_Matrloaa; 


Recommended 

ganarlo 

typa  Jtxaal  la  (<>)  ; 

typa  Rxaa2  la  (<>) ; 

typa  AxaaJ  la  (<>); 

typa  l>aft_Elaa>anta  la  dlglta  <>; 
typa  Rlght_BlaaMnta  la  dlglta  <>; 
typa  Raault_Elaaanta  la  dlglta  <>; 

typa  Laft_Matrlaaa  la  array  (Axaal,  Axaa2)  of  Laft_Elaaanta; 

typo  RightJKatriaaa  la  array  (Axaa2 ,  AxaaS)  of  Rlght_ElaaMmta ; 

typa  Raault_Matrloaa  la  array  (Axaal ,  Axaa3)  of  Raault_ElM«nta ; 

with  function  •**  (Laft  :  Laft_Elaaanta; 

Right  :  Rlght_Elaaanta)  raturn  Raault_ElaaMnta  la  O; 
function  Matrlx_Matrix_Multiply 

(Matrlxl  :  Laf t_Matrlcaa ; 

Hat r 1x2  :  Rlght_Matrlaaa)  raturn  Raault_Matrloaa; 


Figure  39.  Recommended  Change  lo  Matrix_Matrix_Muiliply 

-  Change  all  Tillers  lo  allow  input  and  output  lo  be  different  types. 

-  Add  a  third-order  filter  for  barometric  altitude  smoothing. 

•  Add  a  part  to  Geometric_Operations  that  computes  the  geodetic  coordinates  (i.e.,  geodetic  latitude 
and  longitude)  of  a  new  point,  given  the  geodetic  coordinates  of  a  starting  point  and  the  distance 
and  heading  from  the  starting  point  to  the  new  point.  This  would  be  useful  for  mission-planning 
and  ground  analysis  software. 

•  Add  a  set  of  WGS84  parts.  WGS84  is  supplanting  WGS72  in  some  cruise  missile  applications. 

•  Add  a  set  of  "flat-earth"  navigation  parts.  Very  short  range  weapons  (e.g..  Have  Slick)  do  not 
require  navigation  algorithms  as  sophisticated  as  those  supplied  by  the  parts. 


87 


b.  Modifications  to  the  CAMP  PCS 


•  Modify  llie  Kalman  Filter  Constructor  to  add  the  following  options: 

-  An  additional  matrix  representation.  The  constructor,  as  currently  implemented,  has  two 
options  for  representing  Kalman  matrices:  full  or  sparse.  The  full-matrix  code  use  less  in¬ 
struction  memory,  but  more  operand  memory  and  is  relatively  slow.  The  sparse-matrix  code 
uses  much  more  instruction  memory,  but  is  relatively  fast.  Neither  was  acceptable  for  the 
11th  Missile  Application.  Other  methods  for  representing  and  manipulating  sparse  matrices 
should  be  investigated,  and  at  least  one  additional  method  should  be  implemented  in  the  PCS. 
Any  method  implemented  should  not  be  as  code-intensive  as  the  current  sparse-matrix 
method,  nor  as  data-intensive  as  the  current  full-matrix  method. 

-  Generate  update  control  code  for  multi-measurement-type  filters.  The  generated  code  would 
be  equivalent  to  the  Sequentially_Update_Covariance_Matrix_And_State_Vector  part  for 
single-measurement-type  filters.  The  code  would  be  similar  to  the  body  of  the  part,  except 
that  the  measurement,  measurement-variance,  and  measurement-sensitivity  would  be  variant 
types  (one  variant  for  each  type  of  measurement)  and  the  body  would  contain  a  case  state¬ 
ment  with  one  branch  for  each  variant. 

-  Optionally  include  a  measurement  reasonableness  test. 

-  Optionally  generate  sequential  or  simultaneous  update  code. 

•  Enhance  the  Data  Type  Constructor  to  automatically  generate  floating-point  operators  as  required. 
The  CAMP  parts  are  strongly  typed,  which  means  that  many  operators  are  needed.  The  Basic_ 
Data_Types  part  has  operators  needed  to  instantiate  the  parts.  The  problem  is  that  the  new  code 
written  to  use  the  parts  needs  many  additional  operators.  At  the  very  least,  the  constructor  should 
write  the  body  from  the  function  specification.  At  best,  it  should  also  write  the  specification  based 
on  "missing  function"  compiler  error  messages. 

•  Add  Input/Output  constructors  that: 

-  Generate  records  and  representation  specifications  for  bus  messages  and  I/O  ports. 

-  Generate  functions  to  encode  and  decode  bus  messages. 

-  Generates  a  skeleton  select  statement  that  invokes  the  message  decoding  functions. 

•  Modify  the  Navigation  Constructors  to  generate  an  executive  that  invokes  the  instantiated  parts. 
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c.  Suggested  Ada  Language  Improvements 

Allow  constant  expressions  in  address  clauses.  Il  was  not  possible  to  write  a  single  generic 
package  to  handle  both  Bus-Controller  and  Remote-Terminal  Bus  Interface  Modules  (see  section  V.l.a), 
because  the  interrupt  levels  were  different.  The  address  representation  clause,  which  is  used  to  specify 
the  interrupt  level,  must  use  a  "simple_expression"  for  the  address.  In  other  words,  it  is  impossible  to 
make  the  interrupt  address  a  generic  parameter.  Thus,  the  11th  Missile  Application  contains  two  very 
similar  packages:  one  for  Aus-Controller  BIMs  and  one  for  Remote-Terminal  BIMs. 

Allow  representation  specifications  to  be  separated  from  the  declarations  they  specify.  This 
would  have  permitted  the  11th  Missile  team  to  create  multiple  sets  of  representation  specifications,  one 
set  for  each  compiler  used,  instead  of  creating  tools  to  comment  out  the  specifications  not  applicable  to 
the  compiler  in  use  (see  Section  II. 2.0. 
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THE  APPENDIX 


UTH  MISSILE  USAGE  DATA  BASE 

I.  INTRODUCTION  AND  BACKGROUND 

One  of  the  requirements  of  the  1 1th  Missile  Application  was  that  it  keep  track  of  the  CAMP  parts 
used.  Since  a  database  which  listed  all  the  parts  and  their  sizes  (in  lines  of  Ada  code)  already  existed,  a 
field  to  track  1 1th  Missile  usage  was  added  to  the  tables  that  already  stored  the  sizes.  This  field  allowed  a 
parts  usage  report  to  be  generated  from  the  original  database  relations.  For  a  listing  of  the  relations  and 
their  fields,  see  Volume  I,  Appendix  A. 

More  than  a  simple  list  of  parts  used  was  needed:  information  about  how  a  part  was  used,  who  used 
it,  what  project  the  user  belonged  to,  and  an  additional  remark  also  needed  to  be  tracked.  This  additional 
information  was  stored  in  a  separate  relation,  called  the  Parts.Usage  relation. 

The  Usage  table  and  its  fields  are  shown  in  Table  A-l. 


TABLE  A-l.  PARTS  USAGE  FIELDS  AND  DESCRIPTIONS 


Parts  Usage  Relation 

Column  Name 

Description 

User.Part 

The  put  number  of  the  application  or  CAMP  part  which  makea  uae  of  the  part. 

PartJJsed 

The  part  number  of  the  CAMP  part  being  uaed. 

Project 

The  project  name  of  the  uaer_part. 

Usage_Type 

The  type  of  uaage.  Typea  included  direct,  modified,  and  indirect 

Remark 

A  special  remark  characterizing  or  giving  additional  comments  about  the  parts  uaage. 

It  should  be  noted  that  the  User.Part  and  Part.Used  fields  relate  to  the  part  numbers  that  are  in  the 
TLCSC  and  Adalevel  relations.  This  allows  applications  access  to  the  information  stored  in  these  tables. 
At  present,  since  only  sizes  are  required  in  the  reports  generated,  and  the  sizes  can  be  gotten  more  easily 
from  the  TLCSC  and  Adalevel  relations,  there  are  no  specialized  reports  making  use  of  the  usage  table. 

2.  DATABASE  ISSUES 

There  were  several  issues  concerning  the  Usage  database  which  were  distinct  from  the  size  database. 
The  first  was  how  to  count  modified  code.  The  11th  Missile  Application  counts  a  part  as  used  if  it 
modifies  the  part  for  its  own  usage.  Modification,  of  course,  changes  the  line  count  of  the  part.  The 
database,  however,  maintains  the  line  count  of  the  original  part,  not  the  modified  count.  In  counting  code 
for  the  11th  Missile  Application  parts  usage,  it  was  preferable  to  count  the  modified  lines  of  code  for 
modified  parts.  This  meant  that  these  numbers  had  to  be  put  into  the  reports  manually.  It  didn’t  seem 
feasible  to  put  an  extra  field  in  the  database,  since  the  number  of  parts  actually  modified  was  small. 

Another  issue  was  the  type  of  usage.  The  parts  are  heavily  inter-dependent  (i.e.,  the  parts  use  other 
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parts).  If  the  1 1th  Missile  Application  used  a  part  which  in  turn  used  another  part,  then  both  of  those  parts 
needed  to  be  marked  as  used.  This  means  that  the  parts  usage  of  parts  must  be  derived  from  the  11th 
Missile  usage  list  This  can  be  done  automatically  from  the  Pans _Usage  relation,  but  not  from  the 
TLCSC  and  Adalevcl  relations.  Since  the  usage  information  is  duplicated  in  all  these  tables,  it  is  possible 
to  have  inconsistent  data. 

A  third  difficulty  arose  from  the  nature  of  the  parts.  Since  a  part  could  be  a  TLCSC,  an  LLCSC,  or  a 
unit,  how  to  count  lines  of  code  became  a  problem.  When  the  part  is  a  unit,  often  the  specification  for  the 
part  is  in  a  separate  file,  since  the  CAMP  parts  make  extensive  use  of  separate  compilation  of  Ada  units. 
The  question  then  arises  as  to  whether  the  specification  should  be  counted  or  not.  If  it  is  counted,  it  may 
contain  the  specifications  of  other  pieces  of  a  part  which  were  not  actually  used,  along  with  the  specifica¬ 
tion  that  was  actually  used.  If  it  is  not  counted,  then  the  specification  code  for  the  piece  actually  used 
doesn’t  get  counted.  This  was  handled  on  a  case-by-case  basis .  If  all,  or  most,  of  the  parts  in  a  package 
were  used,  the  specification  code  count  was  included.  If  only  a  few  parts  from  a  package  were  used,  the 
specification  code  count  was  not  included. 

3.  PARTS  USAGE  AND  CODE  COUNT 

The  parts  usage  and  code  count  table  (see  Table  A-2)  is  an  edited  version  of  the  parts  usage  table 
from  Volume  1,  Appendix  A.  The  comment  size,  test  code  size,  and  11th  Missile  usage  columns  were 
deleted,  and  the  "Use  Code"  column  added.  Every  part  has  one  of  the  following  five  usage  codes  as¬ 
signed: 

•  U  (Used):  The  part  was  used  without  modification. 

•  M  (Modified):  The  part  was  used  with  modification. 

•  DF  (Duplicate  Function):  The  part  implements  the  same  function  as  a  part  that  is  used  by  the  1 1th 
Missile. 

•  NA  (Not  Applicable):  The  part  implements  a  function  not  required  by  the  1 1th  Missile. 

•  NC  (Not  Compatible):  The  part  performs  a  function  required  by  the  1 1th  Missile,  but  was  not  used. 

All  part  code  sizes  were  deleted  from  the  table,  except  for  those  parts  used  without  modification. 
The  code  size  totals  were  computed  manually. 
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TABLE  A-2.  PARTS  USAGE  AND  CODE  COUNT 
(Part  1  of  18) 


tlcsc  i 

TLCIC  Hum 

II 

Cod*  Ilia  ||  fart|U*e  || 

Hoaberl 

Lower  LeTel  Unit* 

II 

spec  | 

body  || 

|Cod*|| 

tool 

Coaan  Navigation  tart* 

II 

1 

II 

N 

1  II 

Altitude  Integration 

II 

12  | 

7  II 

I 

1  O  || 

Reinitialise 

II 

2  1 

7  II 

R 

1  II 

Integrate 

II 

3  | 

13  II 

N 

1  II 

Coapute  Ground  Velocity 

II 

10  | 

•  II 

X 

1  <1  II 

Coapute  Gravitational  Acceleration  Lat  In 

II 

1 

II 

I 

1  or  || 

Couput*  Gravitational  Acceleration  tin  Lat  In 

II 

1*  1 

13  II 

X 

1  o  II 

Coaputa  Heading 

II 

1 

II 

X 

1  »  II 

Update  Valoelty 

II 

20  | 

•  II 

X 

1  O  || 

Reinilialli* 

II 

1  | 

3  II 

N 

1  II 

Update 

II 

«  | 

1«  II 

N 

1  II 

Currant  Valoelty 

II 

1  | 

3  II 

N 

1  II 

fealar  Valoelty 

II 

1 

II 

X 

1  "»  II 

C  caput*  Rotation  Ineraaant* 

II 

1 

II 

X 

1  KA  II 

ICR  tom* 

72 

12 

1 

t002 

1 

Wander  Aziauth  Navigation  farta 

II 

1 

II 

N 

1  II 

1 

Couput*  Earth  Relative  loriiontal  Valoeltlea 

II 

1 

II 

X 

1  or  || 

1 

Compute  Total  Angular  Valoelty 

II 

1 

II 

X 

1  RR  II 

1 

Coupute  Coriolis  Aooalaratlon 

II 

1*  1 

12  II 

T 

1  0  || 

1 

Total  flatters  Rotation  Rat* 

II 

11  1 

*  II 

X 

1  0  || 

1 

Earth  Rotation  Rata 

II 

U  1 

7  II 

X 

1  o  || 

1 

Coapute 

II 

4  | 

11  II 

R 

1  II 

1 

Coapute  Rarth  Relative  Navigation  Rotation  Rate 

II 

1*  1 

13  II 

X 

1  0  II 

1 

C papula  Hander  Aaianth  Angle 

II 

1 

II 

X 

1  Dr  II 

1 

Coapute  Latitude 

II 

1 

II 

X 

1  or  || 

1 

Coapute  Latitude  Using  Arotan 

II 

1 

II 

X 

1  or  n 

! 

C Depute  last  Velocity  with  (in  Coa  In 

II 

11  1 

13  II 

X 

1  0  || 

1 

Coapute  Longitude 

II 

1 

II 

X 

1  or  n 

1 

Conpute  Curvatures 

II 

>1  1 

>0  || 

X 

1  0  || 

1 

Coapute  East  Velocity 

II 

1 

II 

X 

1  or  n 

1 

Coapute  North  Valoelty 

II 

1 

II 

X 

1  or  n 

1 

Coriolis  Acceleration  Iron  Total  Rate* 

II 

1 

II 

T 

1  «  ll 

1 

Canute 

II 

1 

II 

H 

1  II 

1 

Coapute  North  Velocity  with  lin  Cos  In 

II 

U  1 

13  II 

X 

1  o  n 

1 

Coapute  Rarth  Relatlva  Horiiontal  Valoeltias  with  tin  Co 

II 

1 

II 

I 

1  »  II 

1 

Coapute  Latitude  Using  Tvs  Value  Arctangent 

II 

14  1 

1«  II 

I 

1  o  || 

1 

Coapute  Longitude  using  Tvs  Value  Arctangent 

II 

11  1 

11  II 

X 

1  0  || 

1 

Coapute  Hander  Aalaaith  Angle  using  Tvo  Value  Arctangent 

II 

10  | 

12  II 

T 

1  o  II 

IUB  TOTALS 

132 

14* 

20 

tool 

1 

North  feinting  Navigation  farts 

II 

1 

II 

1  II 

1 

Canute  Coriolis  Acceleration 

II 

1 

II 

1  or  || 

1 

Total  flatforu  Rotation  Rates 

II 

1 

II 

1  Df  || 

1 

Rarth  Rotation  Rate 

II 

1 

II 

1  or  || 

1 

Coapute 

II 

1 

II 

1  II 

1 

Rarth  Relative  Navigation  Rotation  Rate 

II 

1 

II 

1  dt  || 

1 

Coapute 

II 

1 

II 

1  II 

1 

Latitude  Integration 

II 

1 

II 

1  or  || 

1 

Reinitialise 

II 

1 

II 

1  II 

1 

Integrate 

II 

1 

II 

1  II 

1 

Longitude  Integration 

II 

1 

II 

1  or  || 

1 

Reinitialise 

II 

1 

II 

1  II 

1 

Integrate 

II 

1 

II 

1  II 

1 

Radius  of  Curvature 

II 

1 

II 

i  or  i| 

1 

Coapute 

II 

1 

II 

1  II 

SUBTOTALS 

0 

0 

1 
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TABLE  A-2.  PARTS  USAGE  AND  CODE  COUNT 


(Part  2  of  18) 

flCSC  |  TLCSC  law 

tabor  j  Lowox  Laval  Onita 


||  Coda  Ilia  ||  Fart|Uaa  || 
||  apao  |  body  II  |Codo|| 


13(1  |  Qanaral  Otilitiaa 

j  Inatruotion  (at  Taot 


IIU  |  RM72  Ulipaoid  Hatrlo  Data 


0  It  X  |  M  II 


Mil  I  Mlaalla  Radar  Altiaatar  landlar  Farta 
j  favor  Ob 

|  fowax  Off 

j  Soto  Traaaadt  Modo 

j  Soto  Itandby  Hoda 
I  Farforu  Built  la  Taat 

|  Farfora  Built  In  Taat  laquooeo 

j  Road  Altituda  Foot 

I  Raad  Altituda  Intagar 

(BBTOTAtl 
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TABLE  A-2.  PARTS  USAGE  AND  CODE  COUNT 


(Pari  3ofl8) 


TiCSC  I  nc*c  Kim  ||  Cod*  11 M  ||Part|0*a|| 


Ruafcarj 

Lowor  Loral  Unit* 

(1 

•pac  | 

body  || 

|C*d*|| 

P432 

I  Hiaall*  Radar  Altiaatar  Handler  Auto 

II 

1 

II 

IBII 

Goto  Tranaait  Hod* 

II 

1 

II 

i 

II 

Goto  Standby  Hod* 

II 

1 

II 

1 

II 

Parfora  luilt  In  r*#t 

II 

1 

II 

1 

II 

futon  luilt  In  T*<t  Sequano* 

II 

1 

II 

1 

II 

latd  Altitude  r**t 

II 

1 

II 

1 

II 

Road  Altitude  Integer 

II 

1 

II 

1 

II 

SOSTOTALS 

0 

0 

l 

f«33 

■u*  Intarf ac*  fart* 

II 

1 

II 

I 

1  H 

II 

land  Maaaag*  Da Inf  kddraaa  Mo  Walt 

II 

1 

II 

H 

1 

II 

Sand  Maaaag*  Oalng  Addraaa  Walt 

II 

1 

II 

R 

1 

II 

Data  Tranafar  No  Walt 

II 

1 

II 

1 

1 

II 

Data  Tranafar  Walt 

II 

1 

II 

H 

1 

II 

Parfora  luilt  In  Taat 

II 

1 

II 

1 

1 

II 

Intarfaoa 

II 

1 

II 

H 

1 

II 

Dpdata  Ratty  Count 

II 

1 

II 

H 

1 

II 

Sand  Coanand  Walt 

II 

1 

II 

1 

1 

II 

•and  Maaaag*  Ho  Walt 

II 

1 

It 

H 

1 

II 

Sand  Maaaag*  Walt 

II 

1 

II 

H 

1 

II 

SDSTOTRU 

0 

0 

1 

f«34 

1 

Clock  Handlar 

II 

3  1 

11 II 

I 

1  o 

II 

1 

Currant  Tlaa 

II 

1  1 

3  II 

II 

1 

II 

1 

Converted  Tlaa 

II 

i  1 

4  II 

N 

1 

II 

1 

Raaat  Clook 

II 

i  1 

3  II 

H 

1 

II 

1 

Synchronic*  Clock 

II 

KH 

7  II 

H 

1 

II 

1 

Elapaad  Tlaa 

II 

SO 

f  II 

H 

1 

II 

fO» TOTALS 

13 

43 

l 

S444 

1 

Direction  Coaina  Matrix  Operation* 

II 

1  1 

3  II 

W 

1 

II 

1 

DCH  Ganaral  Operation* 

II 

11  1 

11  II 

H 

1 

II 

1 

DCM  Inltlalixad  Turn  Rafarano* 

II 

13  | 

41  II 

I 

1  0 

II 

1 

DCH  Trapaioidal  Integration 

It 

1 

II 

I 

1  Of  II 

1 

Rainltialia*  Angular  Valocitia* 

II 

1 

II 

R 

1 

II 

1 

farfora  Trapaioidal  Integration  of  DCH 

II 

1 

II 

1 

1 

II 

1 

Sarfera  Rectangular  Integration  of  DCH 

II 

14  | 

r  II 

I 

1  0 

II 

1 

Reorthonoraallia  DCM 

II 

1>  1 

33  II 

I 

1  o 

II 

1 

Traa*  Klaallgnaant 

II 

1*  1 

14  II 

T 

1  0 

II 

1 

Aligned  DCH  Hatrix 

II 

If  | 

14  II 

T 

1  o 

II 

1 

DCM  Troa  Quatarnlon 

II 

1<  1 

37  II 

T 

1  o 

II 

1 

Coaput*  rirat  Row  froa  Orthenorual 

II 

14  | 

11  II 

I 

1  0 

II 

1 

CMC  Operation* 

II 

If  | 

1<  II 

H 

1 

II 

1 

Raorthonoraallra  CMC 

II 

1  | 

4  II 

T 

1  0 

II 

1 

CMI  Inltialiiad  Frea  Earth  Poaltion 

II 

13  1 

11  II 

T 

1  0 

II 

1 

CMI  Integration 

II 

14  1 

11  II 

I 

1  0 

II 

1 

Parfora  Trapaioidal  Integration  of  CMI 

II 

3  1 

f  II 

H 

1 

II 

1 

Rainit  Kng  Val  For  Trapar  Intag  of  CMI 

II 

3  | 

•  II 

1 

1 

11 

1 

Parfora  Rectangular  Integration  of  CMI 

II 

3  1 

7  II 

N 

1 

II 

1 

Alignaant  Part* 

II 

11  1 

21  II 

T 

1  o 

II 

1 

Fraa*  Hiaalignaant  of  CMI 

II 

4  | 

7  II 

N 

1 

II 

1 

Alignad  CMI  Hatix 

II 

4  | 

7  II 

R 

1 

II 

1 

CMI  Troa  Quatarnlon 

II 

13  1 

11  II 

T 

1  o 

II 

1 

Coaput*  OB 

II 

3  | 

«  II 

R 

1 

II 

1 

Coaput*  Tint  Row  of  CHI  Troa  Orthonoraal 

II 

2  | 

3  II 

I 

!  0 

II 

1 

CMI  Inltlalixad  Frea  Rafarano* 

II 

f  | 

17  II 

X 

1  V 

II 

iniOTU! 

310 

407 

13 

95 


TABLE  A- 2.  PARTS  USAGE  AND  CODE  COUNT 


(Part  4  of  18) 


TICK  | 

TLCfC  Him 

II 

Coda  flax  1 |  » 

■rt|Oaa  || 

*1 

Lome  Laval  Onlto 

II 

apoa  | 

body  || 

ICadall 

MSI 

Kalaaa  111  tar  Coeatoa  tarta 

II 

1 

II 

1  II 

ttata  Triultloa  lad  Ireean  Nslia  Matrioae  Hangar 

II 

J1  | 

10  || 

1  0  II 

laltlallra 

II 

1  1 

0  II 

1  II 

trapagate 

II 

J  1 

10  || 

1  II 

Oat  Carraat 

II 

3  1 

7  II 

1  1  II 

trepagated  Ihi 

II 

1  1 

3  II 

1  II 

Error  Covariance  Matrix  Hiaagar 

II 

13  | 

*  II 

1  0  II 

Xaltlalira 

II 

1  1 

3  II 

1  II 

Irapagata 

II 

3  1 

*  II 

1  II 

1 

II 

1  1 

3  II 

1  II 

ttata  Traaaitlon  Matrix  Hiaagar 

II 

1 

II 

1  or  || 

trepagatad  thi 

II 

1 

II 

1  II 

Xaltlalira 

II 

1 

II 

1  II 

Irapagata 

II 

1 

II 

1  II 

eoetotale 

SI 

02 

3 

1*52 

1 

Kalaaa  llltar  Ceapaet  ■  tarta 

II 

1 

II 

1  II 

1 

Capita  Kalaaa  Qaia 

II 

3*  1 

30  II 

1  O  II 

1 

Opdata  Error  Cevariaaca  Matrix 

II 

1 

II 

1  W  II 

1 

Opdata  Etata  Vaeter 

II 

20  | 

33  || 

1  V  II 

1 

tegeeatially  Opdata  Covarlaaoa  Hat r lx  and  Etata  Vector 

II 

1 

II 

1  DC  II 

1 

Opdata 

II 

1 

II 

1  II 

1 

Kalaaa  Opdata 

II 

1 

II 

1  *  II 

1 

Opdata 

II 

1 

II 

1  II 

1 

Opdata  Error  Cevarlaaee  Katrix  Oaaaral  rota 

II 

3*  1 

37  || 

1  »  || 

EOBTOIILS 

ff 

It 

0 

1151 

1 

Kalaaa  llltar  Co^lioated  1  larta 

II 

1 

II 

1  II 

1 

Ceapata  Kalaaa  Oala 

II 

SO  | 

30  || 

1  O  II 

1 

Opdata  Error  Covarlaaoa  Hatrir 

II 

1 

II 

1  w  II 

1 

Opdata  Etata  Vaoter 

II 

30  | 

34  || 

1  o  II 

1 

togaaatlally  Opdata  Covariaaoo  Hatrir  aad  Etata  Vaotor 

II 

1 

II 

1  K  II 

1 

Opdata 

II 

1 

II 

1  II 

1 

Kaliaa  Opdata 

II 

1 

II 

1  K  II 

i 

Opdata 

II 

1 

II 

1  II 

1 

Opdata  Error  Covariaaee  Hatrir  Oaaaral  Iota 

II 

33  | 

37  || 

1  V  || 

fOBTOnU  II  SI  * 


tool  | 

Haypalat  ttaarlag 

II 

1 

II 

M  1 

II 

1 

Dlataaaa  te  Carraat  Haypalat 

II 

1 

II 

*  1 

or 

II 

1 

Caapata  Taraiag  aad  Haataralag  Dlataaeaa 

II 

33  | 

14 

II 

*  1 

0 

II 

1 

Vara  Vaat  Oparatloar 

II 

3  | 

14 

II 

T  1 

0 

II 

1 

ftap  (aat 

II 

4  | 

13 

II 

■  1 

II 

1 

Start  Tart 

II 

4  | 

13 

II 

■  1 

II 

1 

ttaarlag  Vaeter  Operatloea 

II 

1 

II 

*  1 

or 

II 

1 

Xaltlalira 

II 

1 

II 

»  1 

II 

1 

Opdata 

II 

1 

II 

*  1 

II 

1 

ttaarlag  Vaotor  Oparatloar  with  kreaia 

II 

24  | 

23 

II 

*  1 

0 

II 

1 

Xaltlalira 

II 

12  1 

40 

II 

H  1 

II 

1 

Opdata 

II 

0  | 

23 

II 

II 

1 

Coapata  Tara  Angle  aad  Direction 

II 

30  | 

24 

II 

*  1 

0 

II 

1 

Creeatraek  aad  Heading  Error  Operation* 

II 

1 

33 

II 

*  1 

H 

II 

1 

Caapata  When  net  Taraiag 

II 

1 

II 

K  1 

II 

1 

Ceapata 

II 

1 

II 

»  1 

II 

1 

Ceapata  Whan  Taraiag 

II 

33  | 

43 

II 

»  1 

II 

1 

Dietanoa  to  Carraot  Waypoint  with  Area in 

II 

30  | 

11 

II 

X  1 

O 

II 

EOBTOTALE 

117 

231 

0 
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TABLE  A-2.  PARTS 


(Part  5 

TLCfC  |  TLCsfC  Him 
Nuaberj  tower  Level  Dnlte 


Autopilot 

Integral  Flue  Proportional  Gain 
Integrate 

Update  Proportional  Gain 
Pitch  Autopilot 

Initialite  Pitch  Autopilot 
Compute  (levator  Coaaand 
Update  Pitch  Rate  Gain 
Update  Acceleration  Gain 
Update  Integrator  Gain 
Update  Integrator  Unit 
Update  Proportional  Gain 
Lateral  Directional  Autopilot 
Initiallie  Lateral  Directional  Autopilot 
Coapute  Aileron  Rudder  Coaaanda 
Update  Aileron  Integrator  Gain 
Update  Aileron  Integrator  Liait 
Update  Roll  Coaeand  Proportional  Gain 
Update  Roll  Rate  Oain  For  Aileron 
Update  law  Rate  Gain  For  Aileron 
Update  Rudder  Integrator  Gain 
Update  Rudder  Integrator  Liait 
Update  Feedback  Rate  Gain  For  Rudder 
Update  Roll  Rate  Gain  For  Rudder 
Update  Acceleration  Proportional  Gain 

IU1TOTALI 


PCT1 


Air  Data  Parta 

Coapute  Outaide  Air  Teaperatura 
Coapute  Freoaure  Ratio 
Coapute  Haeh 
Coapute  Dynaaie  Preaaure 
Coapute  I peed  of  Pound 
■areaatrio  Altitude  Integration 
Coapute  Bareaotrlc  Altitude 


PC72 


Fuel  Control  Parta 
Throttle  Coaaand  Manager 
Coapute  Throttle  Coaaand 
Update  Mach  Error  Liait 
Update  Mach  Error  Integral  Liait 
Update  Throttle  Rate  Liait 
Update  Throttle  Coaaand  Unite 
Update  Mach  Error  Gain 
Update  Throttle  landwidth 


E  AND  CODE  COUNT 
18) 


| |  Code  (lie  | |  Part|Uae  | | 
II  »P«o  I  body  ||  ICodell 


Oanaral  Victor  Matrix  Algebra 

II 

1 

II 

M 

1 

111  Trana_Dyna«_*parae_ltatrlx_f<j_M*trix 

II 

1 

II 

M 

1 

AiA_Tranapoae~ 

II 

1 

II 

Y 

1  MC 

111  Trana_Vector_l<jJtatrix 

II 

1 

II 

M 

1 

AlA_Tranapoae 

II 

1 

II 

I 

1  K 

1U  Trana_Vector_Soalar 

II 

1 

II 

M 

1 

AlA_Tranapoae 

II 

1 

II 

I 

1  MC 

Coluan  Matrix  Oparatlona 

II 

12  1 

7  II 

M 

1 

letJBiagonaT_and_Subtract_fraa_Identity 

II 

J  | 

11  II 

r 

1  o 

AAA~?ranapoae  ~ 

II 

1 

II 

i 

1  MA 

Mljja  Tnnapeaa 

II 

t  | 

JT  || 

T 

1  o 

Dat  Product  Oparatlona  Ubraatrletad 

II 

1 

II 

M 

1 

Dot  Product 

II 

1 

II 

I 

1  MM 

Dot  Product  Oparatlona  Maatrletad 

II 

1 

II 

Y 

1  Me 

Diagonal  Pull  Matrlr  add  Onraatriotad 

II 

1 

II 

N 

1 

■+■ 

II 

1 

II 

I 

1  w 

Diagonal  Pull  Matrix  Add  Maatrletad 

II 

10  | 

21  II 

r 

1  o 

Matrix  lealar  Oparatlona  Conatralnad 

II 

1 

II 

N 

1 

II 

1 

II 

T 

1  MA 

*/■ 

II 

1 

II 

T 

1  MM 

Diagonal  Matrix  Scalar  Oparatlona 

II 

IS  | 

11  II 

N 

1 

II 

2  1 

1*  II 

Y 

1  o 

■/' 

II 

1 

II 

I 

1  MA 

Matrix  Vactor  Multiply  Ohraatrlctad 

II 

1 

II 

H 

1 

II 

1 

II 

Y 

1  MC 

Matrix  Vactor  Multiply  Maatrletad 

II 

1 

II 

Y 

1  MC 

Vactor  Matrix  Multiply  Unreatrieted 

II 

1 

II 

X 

1 

>»* 

II 

1 

II 

Y 

1  DP  || 

Vactor  Matrix  Multiply  Maatrletad 

II 

1 

II 

Y 

1  MC 

II 
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TABLE  A-2.  PARTS  USAGE  AND  CODE  COUNT 


(Part  7  of  18) 


nc«c  | 

Rwber| 

TLCfC  Mia* 

Lower  Level  Unit* 

1! 

II 

Code  Slxe  ||  tart | Dee  || 
apeo  |  body  |j  ICodejl 

1 

Vector  Vector  Tranapoae  Multiply  Onreatrieted 

II 

1 

II 

M 

1  II 

1 

•** 

II 

1 

II 

T 

1  Dr  II 

1 

Vector  Vector  Tranapoae  Multiply  Raatrieted 

II 

IS  | 

1<  II 

I 

1  °  II 

1 

Matrix  Matrix  Multiply  Onreatrieted 

II 

1 

II 

M 

1  II 

1 

«»■ 

II 

1 

II 

I 

1  or  || 

1 

Matrix  Matrix  Multiply  Reetrieted 

II 

1 

20  || 

I 

1  o  II 

1 

Matrix  Matrix  Tranepoee  Multiply  Onreatrioed 

II 

1 

II 

M 

1  II 

1 

II 

1 

II 

I 

1  »  II 

1 

Matrix  Matrix  Tranapoae  Multiply  Raatrieted 

II 

1 

II 

I 

1  n  II 

1 

lyaaetric  Full  Stonge  Matrix  Operation*  Conatrained 

II 

1  | 

IS  II 

H 

1  II 

1 

Change  Eleaent 

II 

1 

II 

I 

1  »c  II 

1 

Set_to_Identlty_Matri* 

II 

1 

II 

I 

1  ma  h 

I 

Set~to~Iero  Matrix 

II 

1  | 

s  II 

I 

1  o  II 

1 

Add- to~Identi  ty 

II 

1 

II 

I 

1  »  II 

1 

Subtract  froa  Identity 

II 

1 

II 

I 

1  »  II 

1 

■+■  -  ~ 

II 

2  1 

SO  II 

I 

1  0  II 

1 

a  _  a 

II 

1 

II 

I 

1  »  II 

1 

Diagonal  Matrix  Operatlona 

II 

1 

II 

R 

1  II 

1 

Identlty_Natrii 

II 

1 

II 

X 

1  ka  II 

1 

lerejtatrix 

II 

1 

II 

X 

1  »  II 

1 

Change  Xleeiant 

II 

1 

II 

X 

1  NC  II 

1 

Retrieve  Klaaent 

II 

1 

II 

X 

1  «  II 

1 

Row_flioe 

II 

1 

II 

X 

1  MA  II 

1 

Colan_flloe 

II 

1 

II 

X 

1  MA  II 

1 

Add  to  Identity 

II 

1 

II 

X 

1  M  II 

1 

Subtract  froa  Identity 

II 

1 

II 

X 

1  MA  || 

1 

II 

1 

II 

X 

1  MR  || 

1 

II 

1 

II 

I 

1  ma  || 

1 

Vector  Scalar  Operatlona  Onoona trained 

II 

1 

II 

M 

1  II 

1 

**• 

II 

1 

II 

X 

1  or  II 

1 

V 

II 

1 

II 

X 

1  or  II 

1 

Vector  Scalar  Operatlona  Conatrained 

II 

14  1 

3  II 

M 

1  II 

1 

II 

2  | 

11  II 

X 

1  o  II 

1 

■/* 

II 

2  | 

11  II 

X 

1  o  II 

1 

Matrix  Scalar  Operatlona  Onconatralned 

II 

1 

II 

M 

1  II 

1 

II 

1 

II 

X 

1  ma  n 

1 

V 

II 

1 

II 

I 

1  MR  || 

1 

lyaaetrio  Half  Storage  Matrix  Operatlona 

II 

1 

II 

H 

1  II 

1 

Initlalixe 

II 

1 

II 

M 

1  II 

1 

IdentityJUtrlx 

II 

I 

II 

I 

1  or  || 

1 

Zero  Matrix 

II 

1 

II 

X 

1  or  || 

1 

Change_Ileawnt 

II 

1 

II 

X 

1  or  || 

1 

R*trieve_El*aent 

II 

1 

II 

X 

1  or  || 

1 

Row_*lice 

II 

1 

II 

X 

1  or  || 

1 

Coluanllice 

II 

1 

II 

X 

1  or  || 

1 

Add  to~Identity 

II 

1 

II 

X 

1  or  || 

1 

Subtract  froa  Identity 

II 

1 

II 

X 

1  or  || 

1 

•+• 

II 

1 

II 

X 

1  or  || 

1 

a  m  m 

II 

1 

II 

I 

1  or  n 

1 

Swap  Col 

II 

1 

II 

M 

1  II 

1 

Swap" Row 

II 

1 

II 

M 

1  II 

1 

lymetrio  Full  Storage  Matrix  Operation*  Onconatralned 

II 

1 

II 

H 

1  II 

1 

Change  lleaent 

II 

1 

II 

X 

1  or  || 

1 

Set_to~Identlty_Matrix 

II 

1 

II 

X 

1  or  n 

1 

Set~to~lero  Matrix 

II 

1 

II 

X 

1  or  || 

1 

Add- to~Identlty 

II 

1 

II 

X 

1  or  n 

1 

Subtract  froa  Identity 

II 

1 

II 

X 

1  or  || 

1 

"♦* 

II 

1 

II 

I 

1  or  n 

1 

■ . " 

II 

1 

II 

X 

1  or  || 
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TABLE  A-2.  PARTS  USAGE  AND  CODE  COUNT 


(Pari  8  of  18) 


nctc  i 

TLCtC  Him 

II 

Coda  lite  ||  PartlOaa  || 

Nunberj 

Lower  Level  Unit* 

II 

apee  | 

body  II 

|Code|| 

1 

Hotrlz  Oparationa  Onoonatrainad 

II 

1 

II 

R 

1  II 

1 

II 

1 

II 

x 

1  or  II 

1 

II 

1 

II 

r 

1  or  II 

1 

II 

1 

II 

T 

1  or  || 

1 

B.B 

II 

1 

II 

r 

1  or  ii 

1 

fat  to  Idontlty  Matrix 

II 

1 

II 

X 

1  or  ii 

1 

lot  to  loro  Matrix 

II 

1 

II 

X 

1  or  ii 

1 

II 

1 

II 

X 

1  or  || 

1 

Matrix  Oparatiena  Conatraiaod 

II 

I 

II 

M 

1  II 

1 

II 

1 

II 

X 

1  or  || 

1 

nm  m 

II 

1 

II 

X 

1  or  n 

1 

R|R 

II 

1 

II 

X 

1  or  || 

1 

M.B 

II 

1 

II 

X 

1  or  || 

1 

fat  to  Identity  Matrix 

II 

1 

II 

X 

1  Dr  || 

1 

tot  to  taro  Matrix 

II 

1 

II 

X 

1  or  || 

1 

Dynamically  Sparaa  Matrix  Oparationa  Onoonatrainad 

II 

1 

II 

N 

1  II 

1 

tat  to  Identity  Matrix 

II 

1 

II 

T 

1  or  || 

1 

tat  to  taro  Matrix 

II 

1 

II 

X 

1  or  || 

1 

Add~ to~Identity 

II 

1 

II 

X 

1  or  ii 

1 

fublraot  froa  Identity 

II 

1 

II 

X 

1  or  n 

1 

N^H 

II 

1 

II 

X 

1  or  n 

1 

M  —  M 

II 

1 

II 

X 

1  or  n 

1 

Dynamically  tparaa  Matrix  Oparationa  Conatraiaod 

II 

1 

II 

1 

1  II 

1 

fat  to  taro  Matrix 

II 

1 

II 

T 

1  SC  II 

1 

1 

ldd~to~Idan?lty 
fu&raat  froa  Identity 

II 

II 

1 

1 

II 

II 

X 

I 

1  RC  II 

1  K  II 

1 

N^N 

II 

1 

II 

X 

1  n  II 

1 

II 

1 

II 

X 

1  »  II 

1 

tat  to  Idantity  Matrix 

II 

1 

II 

X 

1  »c  II 

1 

Vaetor  Oparationa  Onoonatrainad 

II 

1 

II 

* 

1  II 

1 

M^n 

II 

1 

II 

X 

1  or  || 

1 

M.B 

II 

1 

II 

X 

1  or  || 

1 

Dot  Product 

II 

1 

II 

X 

1  or  || 

1 

Vector  Length 

II 

1 

II 

X 

1  or  || 

1 

Vaetor  Oparationa  Conatrainad 

II 

13  | 

^  II 

N 

1  II 

1 

Dot  Product 

II 

1 

II 

X 

1  »  || 

1 

Voder  Length 

II 

1 

II 

X 

1  n  ii 

1 

II 

2  | 

H  || 

X 

1  0  || 

1 

II 

1 

II 

X 

1  »  II 

wit onu 

12* 

242 

17 
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TABLE  A-2.  PARTS  USAGE  AND  CODE  COUNT 


(Part  9  of  18) 


TLCIC  | 

TLCIC  Hum 

II 

Code  lire  1 1  tart |0*o  1 1 

NUaborl 

IiOMr  Level  (blit* 

II 

•poo  | 

body  || 

ICodell 

Ml)  | 

Itandard  Trig 

II 

13  | 

II 

R 

1  II 

Aretaa2 

II 

11  1 

11  II 

T 

1  o  II 

fin 

II 

1 

II 

T 

1  N  II 

fin 

II 

1 

II 

I 

|  HA  || 

| 

•in 

II 

1 

II 

T 

|  HA  || 

Coa 

II 

1 

II 

I 

1  *  || 

Co* 

II 

1 

II 

I 

1  HA  || 

Coa 

II 

1 

II 

I 

1  Mb  II 

fin  Co* 

II 

1 

II 

T 

1  N  || 

*in~Co» 

II 

1 

II 

I 

1  "A  || 

lin~Co* 

II 

1 

II 

I 

1  Mb  II 

Tan 

II 

1 

II 

r 

1  M  II 

Tan 

II 

1 

II 

T 

1  «»  II 

Tan 

II 

1 

II 

r 

1  MA  || 

Are* in 

II 

1 

II 

r 

1  M  II 

Are* in 

II 

1 

II 

T 

1  "b  II 

Are* in 

II 

1 

II 

I 

1  «»  II 

Arooo* 

II 

1 

II 

I 

1  x  II 

Arooo* 

II 

1 

II 

I 

1  MA  || 

Arooo* 

II 

1 

II 

I 

1  «A  II 

Aroain  Arooo* 

II 

1 

II 

r 

1  M  II 

Aroain  Arooo* 

II 

1 

II 

* 

1  >b  || 

Aro*in~Arooo* 

II 

1 

II 

T 

1  "A  || 

Arotu 

II 

1 

II 

I 

1  N  II 

Arotaa 

II 

1 

II 

I 

1  >A  II 

Arotu 

II 

1 

II 

I 

1  MA  || 

fOROTAU 

24 

27 

15 

Mil  | 

Oeeaotrie  Oporttlon* 

It 

1 

II 

H 

1  II 

1 

Unit  Radial  Vector 

II 

15  | 

11  II 

r 

1  0  II 

1 

Unit  Hora*l  Vootor 

II 

1 

II 

T 

1  MA  || 

1 

Coapute  logmont  ud  Unit  Honal  Vootor 

II 

1 

II 

I 

1  w  || 

1 

Coapste  legaent  ud  Unit  Normal  Vootor  with  Aroain 

II 

23  | 

1<  II 

r 

1  o  II 

1 

Croat  Circle  Aro  Length 

II 

1 

II 

T 

1  MA  II 

1 

Compute 

II 

1 

II 

H 

1  II 

fOBlOTAU 

31 

II 

5 
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TABLE  A-2.  PARTS  USAGE  AND  CODE  COUNT 


(Part  10  of  18) 


ncic  | 

Muaberl 

TLCfC  Him 

Lover  Laval  Unit! 

II 

II 

Coda  Site  ||  fart|Uaa  || 
tpao  1  body  ||  (Coda)  | 

Mil  | 

Signal  frooeaalng 

II 

1 

II 

«  1  1! 

1 

Oeoaral  rirat  Order  filter 

II 

1 

II 

T  |  N  || 

1 

Update  Coefficient! 

II 

1 

II 

K  1  II 

1 

filtar 

II 

1 

II 

«  1  II 

1 

Aaialtlalisa 

II 

1 

II 

»  1  II 

1 

Tnatln  Laad  Lag  filtar 

II 

1 

II 

2  1  "Ml 

1 

Updata  Ceaffioianta 

II 

1 

II 

"  1  II 

1 

filtar 

II 

1 

M 

"  1  II 

1 

Bainitlallsa 

II 

1 

II 

"  1  II 

1 

Tnatln  Lag  filtar 

II 

1 

II 

T  |  "A  || 

1 

Updata  Ceaffioianta 

II 

1 

II 

"  1  II 

1 

filtar 

II 

1 

II 

*  1  II 

1 

Malaltlaliia 

II 

1 

II 

"  1  II 

1 

Saoend  Ordar  filtar 

II 

1 

II 

T  |  "A  || 

1 

Badafina  Coaffielanta 

II 

1 

II 

"  1  II 

1 

filtar 

II 

1 

II 

■  1  II 

1 

Rainltlalira 

II 

1 

II 

«  1  II 

1 

Tnatln  Xntagrator  Kith  Limit 

II 

1 

II 

i  mu 

1 

Updata  Limit 

II 

1 

II 

"  1  II 

1 

Updata  Oain 

II 

1 

II 

■  i  it 

1 

Integra ta 

II 

1 

II 

"  1  II 

1 

Be  eat 

II 

1 

II 

"  1  II 

1 

Limit  flag  Setting 

II 

1 

II 

■  1  II 

1 

Tnatln  Integrator  With  Aaynmetric  Limit 

II 

1 

II 

T  |  "A  || 

1 

Updata  Limita 

II 

1 

II 

"  1  II 

1 

Updata  Oain 

II 

1 

II 

"  1  II 

1 

Integrate 

II 

1 

II 

"  1  II 

1 

Baaat 

II 

1 

II 

"  1  II 

1 

Limit  flag  Setting 

II 

1 

II 

"  1  II 

1 

Upper  Lever  Limiter 

II 

•  1 

12  || 

T  1  0  || 

1 

Updata  Limita 

II 

2  1 

U  || 

"  1  II 

1 

Limit 

II 

1  1 

U  II 

>  1  II 

1 

Upper  Llaitar 

II 

<  1 

1  II 

2  1  0  II 

1 

Updata  Limit 

II 

1  1 

3  II 

H  1  II 

1 

Limit 

II 

1  1 

11  II 

H  1  II 

1 

Lever  Limiter 

II 

«  1 

1  II 

»  1  0  || 

1 

Updata  Limit 

II 

1  1 

<  II 

"  1  II 

1 

Limit 

II 

1  1 

11  II 

"  1  II 

1 

Abaelnta  Limiter 

II 

«  1 

1  II 

»  1  0  II 

1 

Updata  Limit 

II 

1  1 

3  II 

"  1  II 

1 

Limit 

II 

1  1 

13  II 

*  1  II 

1 

Abaolute  Limiter  Kith  flag 

II 

1 

II 

2  1  "A  II 

1 

Limit  flag  Setting 

II 

1 

II 

«  1  II 

1 

Limit 

II 

1 

II 

"  1  II 

1 

Updata  Limit 

II 

1 

II 

"  1  II 

SUBTOTAL! 

15 

lit 

11 

TABLE  A-2.  PARTS  USAGE  AND  CODE  COUNT 


(Part  II  of  18) 


TICK  | 
Rtaber| 

TLCJC  Him 

Lover  Laval  Unite 

II 

II 

Code  Ilia  ||  Pa 
speo  |  body  || 

rt|0ee  || 
ICodell 

PRR7  | 

Ganaril  Purpose  Hath 

II 

1 

II 

1  II 

1 

Integrator 

II 

1 

II 

1  HR  II 

1 

Reinitialise 

II 

1 

II 

1  II 

1 

Update 

II 

1 

II 

1  II 

1 

Integrate 

II 

1 

II 

1  II 

1 

Interpolate  or  Extrapolate 

II 

1 

II 

1  HA  f| 

1 

Square  Root 

II 

7  | 

II 

1  N  || 

1 

Iqrt 

II 

1  | 

II 

1  II 

1 

Root  Sun  Of  Squarea 

II 

11  1 

»  II 

1  o  II 

1 

Riga 

II 

1 

II 

1  HA  || 

1 

Mean  Value 

II 

1 

II 

1  ha  || 

1 

Naan  Abaoluta  Difference 

II 

1 

II 

1  HR  II 

1 

Two  Ray  Table  Lookup 

II 

1 

II 

1  HR  II 

1 

Initlaliie 

II 

1 

II 

1  II 

1 

Lookup  T 

II 

1 

II 

1  II 

1 

Lookup  X 

II 

1 

II 

1  II 

1 

Lookup  Table  Ivan  fpaoing 

II 

1 

II 

1  HA  II 

1 

Initlaliie 

II 

1 

II 

1  II 

1 

Lookup 

II 

1 

II 

1  II 

1 

Lookup 

II 

1 

II 

1  II 

1 

Lookup  Table  Uneven  Spacing 

II 

1 

II 

1  ha  II 

1 

Initlaliie 

II 

1 

II 

1  II 

1 

Lookup 

II 

1 

II 

1  II 

1 

Lookup 

II 

1 

II 

1  II 

1 

Ineraaontor 

II 

1 

II 

1  HA  II 

1 

Relnitiallie 

II 

1 

II 

1  II 

! 

Inoraaaent 

II 

1 

II 

1  II 

1 

Daereaontor 

II 

1 

II 

1  HR  II 

1 

Relnitiallie 

II 

1 

II 

1  II 

1 

Deoieaant 

II 

1 

II 

1  II 

1 

Running  Average 

II 

1 

II 

1  HR  II 

1 

Rainitlaliie 

II 

1 

II 

1  II 

1 

Ra initial lie 

II 

1 

II 

1  II 

1 

Current  Average 

II 

1 

II 

1  II 

1 

Anouaulator 

II 

«  1 

»  II 

1  0  II 

1 

Rainitlaliie 

II 

1  1 

s  II 

1  II 

1 

Aocunulata 

II 

1  1 

»  II 

1  II 

1 

Aoaunulate 

II 

2  1 

«  II 

1  II 

1 

Retrieve 

II 

1  1 

i  II 

1  II 

1 

Change  Caleulator 

II 

II 

1  HR  It 

1 

Relnitiallie 

It 

1 

II 

1  II 

1 

Change 

If 

1 

II 

1  II 

1 

Retrieve  Value 

II 

1 

II 

1  II 

1 

Change  Anouaulator 

II 

1 

II 

1  ha  II 

1 

Rainitlaliie 

II 

1 

II 

1  II 

1 

Relnitiallie 

II 

1 

II 

1  II 

1 

Aoeuaulate  Change 

II 

1 

II 

1  II 

1 

Aocunulata  Change 

II 

1 

II 

1  II 

1 

Retrieve  Accuaulation 

II 

1 

II 

1  II 

1 

Retrieve  Previous  Value 

II 

1 

II 

1  II 

ROITOTALR  JO  41  14 
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TABLE  A-2.  PARTS  USAGE  AND  CODE  COUNT 


ncac 

Motet 


PCM 


(Pari  12  of  18) 


TLCJC  Him 

lo**r  Uni  Unit* 


Polynomial* 

Pa  duct  loo  Operation* 
tin*  Reduction 
Coils*  Reduction 
Taylor  (aria* 

Taylor  natural  Log 
Hat  log  Itora 
Hat  Log  7t*r» 

Hat  Log  <t*ra 
Hat  Log  Stora 
Hat  Log  Itora 
Taylor  Log  laa*  H 
Log  Bai*  H  Itara 
Log  H  Itora 
Log  Haa*  H  Ttara 
Log  H  Ttara 
Log  Haa*  H  Ctara 
Log  H  Itara 
Log  Baa*  H  Stora 
Log  H  Stora 
Log  laao  H  Itora 
Log  H  Itora 

Taylor  Dogroa  Operation! 
Nod  Coa  D  Itora 
Tan  D  Itara 
Mod  Tan  D  Itora 
Nod  Tan  D  Ttara 
Nod  Tan  D  Itora 
Hod  Tan  D  Stora 
Nod  Tan  D  Itara 
tin  D  Itora 
tin  D  Ttara 
tin  D  Itora 
Tin  D  Stora 
Mod  tin  D  Itora 
Mod  tin  D  Ttara 
Nod  tin  0  Itara 
Nod  tin  D  Stora 
Mod  tin  D  Itora 
Coo  D  Itora 
Coa  D  Ttara 
Coa  D  Itora 
Coa  D  Stora 
Coa  D  Itora 
Mod  Co*  D  Itora 
Mod  Coa  D  Ttara 
Mod  Coa  D  Itara 
Nod  Co*  D  Stora 
tin  D  Itora 


||  Coda  Ilia  ||  Part|D*o  || 
||  apoo  |  body  ||  |Codo|| 

II 

II 

R 

1  II 

II  1 

4  II 

H 

1  II 

II  1 

13  II 

T 

1  o  II 

II  1 

«  II 

T 

1  o  II 

II 

II 

H 

1  II 

II 

II 

H 

1  II 

II 

II 

T 

1  BP  || 

II 

II 

» 

1  BP  || 

II 

II 

T 

1  BP  || 

II 

II 

T 

1  BP  || 

II 

II 

r 

1  BP  || 

II 

II 

H 

1  II 

II 

II 

Y 

1  «  II 

II 

II 

H 

1  II 

II 

II 

Y 

1  «  II 

II 

If 

R 

1  II 

II 

II 

Y 

1  n  || 

II 

II 

H 

1  II 

II 

It 

Y 

1  «  II 

II 

II 

H 

1  II 

II 

II 

Y 

1  u  II 

II 

II 

H 

1  II 

II 

II 

H 

1  II 

II 

II 

Y 

1  BP  || 

II 

II 

Y 

1  BY  II 

II 

II 

Y 

1  BY  II 

II 

II 

Y 

1  BP  || 

II 

II 

Y 

1  BP  || 

II 

II 

Y 

1  BP  || 

II 

II 

Y 

1  BY  II 

II 

II 

Y 

1  BY  || 

II 

II 

Y 

1  BP  || 

II 

II 

Y 

1  BP  || 

II 

II 

Y 

1  BY  || 

II 

II 

Y 

1  BP  || 

II 

II 

Y 

1  BP  || 

II 

II 

Y 

1  BY  f| 

II 

II 

Y 

1  BY  || 

II 

II 

Y 

1  DP  || 

II 

II 

Y 

1  BY  || 

II 

II 

Y 

1  DP  || 

II 

II 

Y 

1  DP  || 

II 

II 

Y 

1  DP  || 

II 

II 

H 

1  II 

II 

II 

Y 

1  DP  || 

II 

II 

Y 

1  BY  II 

II 

II 

Y 

1  BY  || 

II 

II 

Y 

1  BP  || 

II 

II 

H 

1  II 
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TABLE  A-2.  PARTS  USAGE  AND  CODE  COUNT 


(Part  13  of  18) 


ncic  | 

Huabarl 

TLCIC  Him 

Loner  Loral  Onita 

II 

II 

Coda  llao  ||!art|Uea|| 
tpae  |  body  ||  |Coda|| 

1 

Taylor  Radian  Operation* 

II 

1 

II 

M 

1  II 

1 

Aretan  R  7tan 

II 

1 

II 

T 

1  Dr  II 

1 

Aretan  R  (tan 

II 

1 

If 

I 

I  or  II 

1 

Aretan  R  Stan 

II 

1 

II 

I 

l  or  ii 

1 

Aretan  R  (tan 

II 

1 

II 

T 

l  or  ii 

1 

Alt  Aretan  R  Itan 

II 

1 

II 

I 

l  or  ii 

1 

Alt  Aretan  R  7ten 

II 

1 

II 

T 

1  or  ii 

1 

Alt  Aretan  R  (tan 

II 

1 

II 

I 

l  or  n 

1 

Alt  Arotan  R  Stan 

II 

1 

II 

T 

1  or  || 

1 

Alt  Aretan  R  (tan 

II 

1 

II 

T 

1  or  ii 

1 

Hod  (in  R  (tan 

II 

1 

II 

I 

l  or  n 

1 

Hod  tin  R  Stan 

II 

1 

II 

T 

l  or  ii 

1 

Hod  Sin  R  (tan 

II 

1 

II 

I 

1  or  n 

1 

Coa  R  Itan 

II 

1 

II 

T 

1  or  || 

1 

Coa  R  7tan 

II 

1 

II 

X 

1  or  ii 

1 

Coa  R  (tan 

II 

1 

II 

T 

1  or  n 

1 

Coa  R  Stan 

II 

1 

II 

I 

1  or  || 

i 

Coa  R  (tan 

II 

1 

II 

I 

1  or  || 

1 

Hod  Coa  R  Itan 

II 

1 

II 

X 

1  or  n 

1 

Hod  Coa  R  7tan 

II 

1 

II 

I 

1  or  || 

1 

Hod  Coa  R  (tan 

II 

1 

II 

X 

1  or  || 

1 

Hod  Coa  R  Stan 

II 

1 

II 

X 

1  or  n 

1 

Hod  Coa  R  (tan 

II 

1 

II 

X 

1  or  n 

1 

Tan  R  Itan 

II 

1 

II 

I 

!  or  n 

1 

Hod  Tan  R  Itan 

II 

1 

II 

X 

i  or  n 

1 

Hod  Tan  R  7tan 

II 

1 

II 

X 

l  or  ii 

1 

Hod  Tan  R  (ton 

II 

1 

II 

X 

l  or  n 

1 

Hod  Tan  R  Stan 

II 

1 

II 

X 

1  Dr  ii 

1 

Hod  Tan  R  Itan 

II 

1 

II 

I 

1  or  ii 

1 

Arealn  R  Itan 

II 

1 

II 

X 

1  or  ii 

1 

Aroaln  R  7ton 

II 

1 

II 

X 

1  or  ii 

1 

Arealn  R  (ton 

II 

1 

II 

X 

1  or  n 

1 

Aroaln  R  Stan 

II 

1 

II 

X 

1  or  ii 

1 

Aroeoa  R  Itan 

II 

1 

II 

X 

1  or  || 

1 

Areooa  R  7ton 

II 

1 

II 

X 

1  Dr  ii 

1 

Aroooa  R  (tan 

II 

1 

II 

X 

l  or  ti 

1 

Areooa  R  Stan 

II 

1 

II 

X 

1  or  ii 

1 

Aretan  R  Itan 

II 

1 

II 

I 

1  or  || 

1 

Sin  R  Itan 

II 

1 

II 

I 

l  or  || 

1 

•In  R  7tan 

II 

1 

II 

X 

1  Dr  || 

1 

Sin  R  (tan 

II 

1 

II 

X 

l  or  n 

1 

Sin  R  Stan 

II 

1 

II 

X 

1  or  || 

1 

tin  R  Itan 

II 

1 

II 

X 

1  or  n 

1 

Hod  tin  R  Itan 

II 

1 

II 

X 

1  or  ii 

1 

Hod  lln  R  7tan 

II 

1 

II 

I 

1  or  ii 

1 

Hodifiad  Newton  Raphaon 

II 

3  | 

•  II 

■ 

1  II 

1 

IqRt 

II 

(  | 

33  II 

X 

1  0  || 

1 

Newton  Raphaon 

II 

1 

II 

1 

1  II 

1 

IqRt 

II 

1 

II 

X 

1  or  ii 
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TABLE  A-2.  PARTS  USAGE  AND  CODE  COUNT 


(Part  14  of  18) 


tlcsc  | 

Hunberj 

TLCSC  Rum 

Lower  Lerol  Unit* 

II 

II 

Cod*  Site  ||  Fart | 
tpee  |  body  ||  | 

0*e  || 
Coda  1 1 

1 

Sy*t«a  Function* 

II 

1 

II 

H 

II 

1 

Saaiolrclo  Operation* 

II 

1 

II 

H 

II 

1 

lin 

II 

1 

II 

T 

or  n 

1 

Co* 

II 

1 

II 

T 

DF  || 

1 

Tin 

II 

1 

II 

T 

or  || 

1 

Arc* in 

II 

1 

II 

T 

or  || 

1 

Arece* 

II 

1 

II 

Y 

or  n 

1 

Aretin 

II 

1 

II 

T 

or  || 

1 

Degree  Operation* 

II 

1 

II 

H 

II 

1 

fin 

II 

1 

II 

T 

or  n 

1 

Co* 

II 

1 

II 

I 

| 

or  || 

1 

Tan 

II 

1 

II 

Y 

or  || 

1 

Aroain 

II 

1 

II 

Y 

or  || 

1 

Arece* 

II 

1 

II 

Y 

or  n 

1 

Arctan 

II 

1 

II 

Y 

or  n 

1 

Square  Root 

II 

1 

II 

Y 

or  || 

1 

Iqrt 

II 

1 

II 

H 

II 

1 

•a*e  10  Logarithm 

II 

1 

II 

Y 

HA  || 

1 

Log  10 

II 

1 

II 

H 

II 

1 

Ba*e  H  Logaritha 

II 

1 

II 

Y 

HA  || 

1 

Log  H 

II 

1 

II 

R 

II 

1 

Radian  Operation* 

II 

1 

II 

R 

II 

1 

Sin 

II 

1 

II 

Y 

or  II 

1 

Co* 

II 

1 

II 

Y 

DF  || 

1 

Tan 

II 

1 

II 

Y 

or  ii 

1 

Are* in 

II 

1 

II 

Y 

or  n 

1 

Arooo* 

II 

1 

II 

Y 

or  n 

1 

Arctan 

II 

1 

II 

Y 

or  ii 

1 

Cody  Raite 

II 

1 

II 

H 

II 

1 

Cody  Hatural  Log 

II 

1 

II 

R 

II 

1 

Rat  Log 

II 

1 

II 

Y 

HA  || 

1 

R 

II 

1 

II 

H 

II 

1 

Defloat 

II 

1 

II 

H 

II 

! 

Cody  Log  Raae  H 

II 

1 

II 

R 

II 

i 

Log  Raae  H 

II 

1 

II 

Y 

HA  II 

i 

Log  R 

II 

1 

II 

H 

II 

i 

Continued  Fraction* 

II 

1 

II 

R 

II 

i 

Continued  Radian  Operation* 

II 

1 

II 

H 

II 

i 

Tan  R 

II 

1 

II 

Y 

or  ii 

i 

Arctan  R 

II 

1 

II 

Y 

or  || 

i 

Flke 

II 

3  | 

5  II 

H 

II 

i 

Flke  Seedcircle  Operation* 

II 

S  | 

10  II 

R 

II 

i 

Arealn  S  Ctera 

II 

1  | 

»  II 

Y 

o  II 

i 

Aroco*  8  Ctera 

II 

1  | 

12  || 

Y 

o  II 

i 

General  Polynomial 

II 

1 

II 

H 

II 

i 

Polynomial 

II 

1 

II 

Y 

HA  II 

i 

Hart 

II 

1 

II 

R 

II 

i 

Hart  Radian  Operation* 

II 

1 

II 

H 

II 

i 

Co*  R  Stern 

II 

1 

II 

Y 

or  n 

i 

Hart  Degree  Operation* 

II 

1 

II 

H 

II 

i 

Co*  D  Stern 

II 

1 

II 

Y 

or  ii 
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TABLE  A-2.  PARTS  USAGE  AND  CODE  COUNT 


(Part  15  of  18) 


TLCSC  | 

TLCSC  Him 

II 

Coda  Site  1 1 

PartlOae  | 

Huaberl 

Lover  Leral  Unita 

II 

apae  | 

body  || 

ICodall 

Rattingi 

II 

1 

11 

R 

II 

Htttingi  Degree  Operation! 

II 

1 

II 

H 

II 

Sin  D  5tana 

II 

1 

II 

Y 

Dr  || 

Sin  D  4ten 

II 

1 

II 

T 

DP  || 

Cet  D  Stan 

II 

1 

II 

Y 

or  it 

Cot  D  4ten 

II 

1 

II 

Y 

or  it 

Tan  D  Stan 

II 

1 

II 

Y 

or  || 

Tan  D  4tan 

II 

1 

II 

Y 

or  || 

Haatinga  Radian  Oparationa 

II 

12  | 

««  II 

a 

II 

Cot  R  Stan 

II 

1  1 

It  II 

Y 

D  II 

Cot  R  4tan 

II 

1  1 

IS  II 

Y 

u  II 

Tan  R  Stan 

II 

1  1 

12  II 

Y 

U  || 

Tan  R  4tan 

II 

1  1 

12  II 

Y 

0  II 

Aretan  R  Stan 

II 

1  1 

11  II 

Y 

0  II 

Aretan  R  Ttan 

II 

1 

II 

Y 

Dr  II 

Arotan  R  Ctan 

II 

1  | 

M  II 

Y 

D  II 

Mad  Aretan  R  Stan 

II 

1 

II 

Y 

or  || 

Mad  Arotan  R  Ttan 

II 

1 

II 

Y 

or  n 

Mod  Aretan  R  Stan 

II 

1 

II 

Y 

or  n 

Sin  R  Stan 

II 

1  | 

1«  II 

Y 

0  II 

Sin  R  4tan 

II 

1  | 

IS  II 

Y 

0  II 

Chabyahar 

II 

1 

II 

■ 

Chabyahar  Radian  Oparationa 

II 

1 

II 

H 

Sin  R  Stan 

II 

1 

II 

Y 

or  || 

Chabyahar  Dagraa  Oparationa 

II 

1 

II 

I 

Sin  D  Stan 

II 

1 

II 

Y 

dp  || 

Chabyahar  Saailairala  Oparatiana 

II 

1 

II 

a 

II 

Sin  S  Stan 

II 

1 

II 

Y 

or  ii 

SUBTOTALS 

IK 

304 

133 

MSI  | 

Abatraet  Data  Structural 

II 

i 

II 

1 

II 

1 

Bounded  Stack 

II 

i 

II 

1 

RA  || 

1 

Clear  Staok 

II 

i 

II 

1 

II 

1 

Addjlannt 

II 

i 

II 

1 

II 

1 

Ratriara  (laaant 

II 

i 

II 

1 

II 

1 

Peak 

II 

i 

II 

1 

II 

1 

Staek  Statua 

II 

i 

II 

1 

ll 

1 

Staek_Langth 

II 

i 

II 

1 

II 

1 

Unbounded  Staek 

ll 

i 

II 

1 

HA  || 

1 

Initialiaa 

II 

i 

II 

1 

II 

1 

Clear  Staek 

II 

i 

II 

1 

II 

1 

Free  Haaery 

II 

i 

II 

1 

II 

1 

Addllennt 

II 

i 

II 

1 

II 

1 

Ratriara  (laaMnt 

II 

i 

II 

1 

II 

1 

Peak 

II 

i 

II 

1 

II 

1 

Staok_Statua 

II 

i 

II 

1 

II 

1 

Staek~Length 

II 

i 

II 

1 

II 

I 

Dot  Next 

II 

i 

II 

1 

II 

1 

Sat~Hext 

II 

i 

II 

1 

II 
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TABLE  A-2.  PARTS  USAGE  AND  CODE  COUNT 


(Part  16  of  18) 


ncic  i 

TLCIC  Mom 

ii 

Coda  Ilia  ||  PartjDaa  || 

Motor  j 

Lome  Laval  Unit* 

ii 

apae  | 

body  || 

|Coda|| 

Dnboundad  PIPO  Buffar 

ii 

1 

II 

r 

1  DP  || 

Xnitialiaa  Buffar 

ii 

1 

II 

N 

1  II 

Clair  Buffar 

it 

1 

II 

M 

1  II 

Proa  Howry 

ii 

1 

II 

N 

1  II 

Add  Ilaaant 

ii 

1 

II 

M 

1  II 

Katriava  Blaaant 

ii 

1 

II 

M 

1  II 

Baak 

ii 

1 

II 

N 

1  II 

Buffar  Itatu* 

ii 

1 

II 

M 

1  II 

Buffar~Langth 

ii 

1 

II 

M 

1  II 

Dot  Mast 

n 

1 

II 

M 

1  II 

lat  Hast 

ii 

1 

II 

N 

1  II 

Honblooklng  Clreular  Buffar 

ii 

20  | 

»  II 

r 

1  U  II 

Claar  Buffar 

n 

1  1 

10  II 

M 

1  II 

Add  Blaaant 

n 

2  1 

20  II 

H 

1  II 

Katriava  Blaaant 

ii 

2  1 

1»  II 

M 

1  II 

Paak 

ii 

1  1 

n  ii 

H 

1  II 

Buffar  Itatua 

n 

1  1 

14  II 

H 

1  II 

Buffar  Langth 

ii 

1  1 

3  II 

N 

1  II 

OnboundaS  Priority  Quaua 

n 

20  1 

32  || 

I 

1  0  II 

Quaua  Itatua 

ii 

1  1 

14  II 

M 

1  II 

Quaua-Langth 

ii 

X  1 

»  II 

N 

1  II 

Dot  Halt 

n 

1  1 

3  II 

M 

1  II 

fat~Haxt 

ii 

2  1 

0  II 

M 

1  II 

IniFialita 

ii 

1  1 

1«  II 

M 

1  II 

Claar  Quaua 

ii 

1  1 

11  II 

M 

1  II 

Proa  Haaory 

n 

1  1 

12  II 

N 

1  II 

Add  Ilaaant 

n 

3  1 

2#  II 

M 

1  II 

Katriava  Blaaant 

n 

2  1 

1*  II 

M 

1  II 

Paak 

ii 

1  1 

12  II 

M 

1  II 

Boundad  riTO  Buffar 

ii 

21  1 

0  II 

Y 

1  0  II 

Paak 

ii 

1  1 

11  II 

M 

1  II 

Buffar  Itatua 

ii 

1  1 

13  II 

N 

1  II 

Buffar  Langth 

ii 

1  1 

3  II 

H 

1  II 

Claar  Suffar 

ii 

1  1 

10  II 

N 

1  II 

Add  Blaaant 

ii 

2  1 

10  II 

M 

1  II 

Katriava  Blaaant 

ii 

2  1 

10  II 

M 

1  II 

Avallabla  Tpaoa  Llat  Oparatlona 

ii 

0  1 

<  II 

N 

1  II 

Haw  Moda 

ii 

0  1 

11  II 

M 

1  II 

lava  Moda 

ii 

0  1 

10  II 

N 

1  II 

lava  Llat 

ii 

0  1 

12  II 

M 

1  II 

I0BT0TALI 

II 

431 

1 

H92  | 

Abatraot  Prooaaaaa 

ii 

1 

II 

Y 

1  N  II 

1 

Pinlta  Itata  Ha china 

ii 

1 

II 

N 

1  II 

1 

Maaly  Naohina 

ii 

1 

II 

M 

1  II 

1 

Bvant-Drivan  laguanoar 

it 

1 

II 

N 

1  II 

1 

Tiaa-Drlvan  Baguancar 

ii 

1 

II 

N 

1  II 

I 

loquono*  Controller 

ii 

1 

II 

N 

1  II 

IOBTOTALI  0  9  1 
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TABLE  A-2.  PARTS  USAGE  AND  CODE  COUNT 


TLCSC 

Ruabar 


PSS1 


(Part  17  of  18) 


TLC8C  Hum  II  Cod*  111*  ||  P*rt|0»*  || 


Lower  L*r*l  Unit* 

II 

apae  | 

body  || 

ICodall 

Unit  Convaraion* 

II 

1 

II 

1 

II 

Kilogram  p*r  H*t*r  Squired  ind  Pound*  par  Toot  Squared 

II 

1 

II 

R 

II 

Convaraion  to  Pound*  p*r  Poot2 

II 

1 

II 

r 

KA  || 

Conr*r»ion  to  Kilogram  par  M*t*r2 

II 

1 

II 

T 

RA  || 

Radian*  and  Saaloirela*  par  Saoond 

II 

1 

II 

N 

II 

Convaraion  to  Saaleirola*  par  Saoond 

II 

1 

II 

T 

RA  || 

Convaraion  to  Radian*  par  Saoond 

II 

1 

II 

T 

HA  || 

D*gr**a  and  Saaioirolaa 

II 

1 

II 

R 

II 

Convaraion  to  Saaloirela* 

II 

1 

II 

T 

HA  || 

Conear* ion  to  Dagroaa 

II 

1 

II 

T 

HA  || 

Dagraa*  and  Saaloireio*  par  Saoond 

II 

1 

II 

H 

II 

Convaraion  to  Saaleirolaa  par  Saoond 

II 

1 

II 

I 

KA  II 

Convaraion  to  Dagraa*  par  Saoond 

II 

1 

II 

T 

HA  || 

Second*  and  Minute* 

II 

1 

II 

R 

II 

Convaraion  to  Mlnutaa 

II 

1 

II 

r 

RA  || 

Convaraion  to  Saoond* 

II 

1 

II 

r 

HA  || 

Cantigrad*  and  Pahranbait 

II 

1 

II 

R 

II 

Converaisn  to  Fahrenheit 

II 

1 

II 

T 

HA  || 

Convaraion  to  Cantigrad* 

II 

1 

II 

T 

RA  || 

Centigrade  and  Kalvin 

II 

1 

II 

R 

II 

Convaraion  to  Kalvin 

II 

1 

II 

T 

HA  || 

Convaraion  to  Cantigrad* 

II 

1 

II 

T 

RA  || 

Pahranhalt  and  Kelvin 

II 

1 

II 

H 

II 

Companion  to  Kelvin 

II 

1 

II 

r 

RA  || 

Companion  to  Pahranhalt 

II 

1 

If 

T 

HA  || 

Kilogram  and  Pound* 

II 

1 

II 

H 

II 

Convaraion  to  Kilogram 

II 

1 

II 

r 

HA  || 

Convaralon  to  Pound* 

II 

1 

II 

i 

RA  II 

Matara  and  Pant  par  Saoond 

II 

1 

II 

H 

II 

Convaraion  to  Poet  par  Saoond 

II 

1 

II 

T 

HA  || 

Convaraion  to  Matara  par  Saoond 

II 

2  | 

3  II 

I 

0  II 

Matara  and  Paat  par  Saoond  Squared 

II 

1 

II 

R 

II 

Convaraion  to  Paat  par  S*oond2 

II 

1 

II 

T 

«  || 

Convaraion  to  Matara  par  I*oond2 

II 

1 

II 

I 

HA  || 

Gaoa  and  Matara  par  Saoond  Squared 

II 

1 

II 

H 

II 

Convaraion  to  Matara  par  S*oond2 

II 

2  | 

3  II 

Y 

0  II 

Convaraion  to  Gam 

II 

1 

II 

I 

HA  || 

Gaea  and  Paat  par  Saoond  Squared 

II 

1 

II 

R 

II 

Convaraion  to  Paat  par  S*eond2 

II 

1 

II 

Y 

HA  || 

Convaraion  to  Cam 

II 

1 

II 

Y 

HA  || 

Radian*  and  Dagraa* 

II 

1 

II 

H 

II 

Convaraion  to  Dagraa* 

II 

1 

II 

Y 

RA  || 

Convaraion  to  Radian* 

II 

1 

II 

Y 

HA  || 

Radian*  and  Dagraa*  par  Saoond 

II 

1 

II 

H 

II 

Convaraion  to  Dagraaa  par  Saoond 

II 

1 

II 

Y 

KA  || 

Convaraion  to  Radlana  par  Saoond 

II 

1 

II 

Y 

HA  || 

Radian*  and  Saaioirolaa 

II 

3  | 

2  II 

R 

II 

Convaraion  to  Saaioirolaa 

II 

1  | 

3  II 

Y 

0  II 

Convaraion  to  Radian* 

II 

1  | 

3  II 

Y 

0  II 

Matara  and  Paat 

II 

1 

II 

H 

II 

Convaraion  to  Foot 

II 

1 

II 

Y 

HA  || 

Convaraion  to  Matara 

II 

1 

II 

Y 

RA  II 

SUBTOTALS  11  22  34 
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TABLE  A-2.  PARTS  USAGE  AND  CODE  COUNT 


(Concluded) 


TLCfC  |  TLCIC  Nam 

Huabarj  Lome  Laval  Unit* 

It 

II 

Cada  liia  ||  tart|Oaa  || 
opaa  |  body  1 1  |Coda|| 

VI52 

|  Extarnal  Ton  Canvaralon  Two*  Coaplaaant 

|  loala 

j  Unioala 

II 

II 

II 

1 

1 

2  1 

II 

II 

1  II 

«  1  II 
r  |  »  || 

T  1  0  || 

aonorui 

2 

1 

2 

MOO 

|  Quatarnion  Oparatlon* 

II 

1 

II 

*  1 

II 

|  Qoatarnlon  Caapotad  Troa  tolar  Angla* 

II 

15  1 

24  || 

r  |  o 

II 

|  Momalliad  Quatarnion 

II 

1 

II 

T  |  HA  || 

j  «*« 

II 

4  1 

24  || 

T  |  0 

II 

■OB TOTAL* 

1* 

SO 

3 

TOTAL* 

1,431 

2,410 

453 

CODI  TOTAL*  3,111 


NO 
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KAMAN  SCIENCES  CORPORATION 
NAVAL  RESEARCH  LAB/CODE  5595 
CARNEGIE  MELLON  UNIV/SEI/SHOLOM 
COLEMAN  RESEARCH  CORP 
COLSA,  INC 

CONTROL  DATA  CORPORATION 
WINTEC 

CONTROL  DATA/DEPT  1855 
DACS/RADC/COED 
RAYTHSON/EQPT  DIV 
BMO/ACD 
DDC-I,  INC 

ENGINEERING  &  ECONOMICS  RESEARCH/ 
DIV  OFFICE 
BDM  CORP 
AFATL/FXG/EVERS 
ESD/SYW-JPMO 

FORD  AEROSPACE  &  COMM  CORP/MS  H04 
UNIV  OF  COLORADO  #202 
ANALYTICS 
AFWAL/FIGL 

WESTINGHOUSE  ELECTRIC  CORP/MS  5220 

GENERAL  DYNAMICS/MZ  W2-5530 

HONEYWELL  INC 

TAMSCO 

STARS 

FORD  AEROSPACE/MS  2/206 
GRUMMAN  HOUSTON  CORPORATION 
NAVAL  AVIONICS  CENTER/NAC-825 
NASA  JOHNSON  SPACE  CENTER/EH/GHG 
BOEING  AEROSP AC E/MS-8 Y97 
HARRIS  CORPORATION/GISD 


1  CARNEGIE  MELLON  UNIV/ 

1  SOFTWARE  ENGINEERING  INST  1 

4  NOAA/ERL/R/E/AL4  1 
1  INTERMETRICS,  INC/G.  RENTH  1 
1  INTERMETRICS,  INC/D. P.  SMITH  1 
1  FORD  AEROSPACE/WEST  DEVEL  DIV  1 
1  AD/ENE  1 
1  ROC  KWELL/MS-GA2 1  1 
1  GRUMMAN  CORP/MS  D-3 1-237  1 
1  INSTITUTE  OF  DEFENSE  ANALYSIS  1 
1  TELEDYNE  BROWN/MS  178  1 
1  USAF/TAWC/SCAM  1 
1  BOEING  AEROSPACE  CO/D.  LINDBERG  1 

5  LOGICON  1 
1  EASTMAN  KODAK/DEPT  47  1 
1  SYSTEMS  CONTROL  TECH,  INC  1 
1  E-SYSTEMS/GARLAND  DIV  1 
1  AFWAL/AAAF  1 
1  MARTIN  DEVELOPMENT  1 
1  MA  COMPUTER  ASSOCIATES  INC  1 
1  IBM  FEDERAL  SYS  DIV/MC  3206C  1 
1  MCDONNELL  DOUGLAS/INCO,  INC  1 
1  UNITED  TECH,  ADVANCED  SYS  1 
1  MCDONNELL  AIRCRAFT  CO/DEPT  300  1 
1  WESTINGHOUSE  ELEC/MS  432  1 
1  MHP  FU-TECH,  INC  1 
1  ITT  AVIONICS  1 
1  COSMIC/UNIV  OF  GA  1 
1  NAVAL  OCEAN  SYS  CENTER/CODE  423  1 
1  NAVAL  WEAPONS  CTR/CODE  3922  1 
1  ODYSSEY  RESEARCH  ASSOCIATES,  INC  1 

USA  ELEC  PROVING  GRD/STEEP  MT-DA  1 
1  PATHFINDER  SYS  1 
1  BDM  CORPORATION  1 
1  PERCEPTRONICS,  INC  1 
1  PHOENIX  INTERNATIONAL  1 
1  MCDONNELL  DOUGLAS  ASTRO  CO  1 
1  GTE  LABORATORY/RUBEN  PRIETO-DIAZ  1 
1  PROPRIETARY  SOFTWARE  SYSTEMS  1 
1  ADVANCED  TECHNOLOGY  8 
1  STANFORD  TELECOMMUNICATIONS,  INC  1 
1  RATIONAL  1 
1  LOCKHEED  MISSILES  &  SPACE  CO  1 
1  HERCULES  DEFENSE  ELEC  SYS  1 
1  AEROSPACE  CORP  1 
1  ROGERS  ENGINEERING  &  ASSOCIATES  1 
1  ADAS OFT  INC  1 
1  ESD/XnSE  1 
1  SANDERS/MER  24-1212  1 
1  CSC/ERIC  SCHACHT  1 
1  COMPUTER  TECH  ASSOCIATES,  INC  1 
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INITIAL  DISTRIBUTION  LIST  (CONCLUDED) 


SCIENCE  APPLICATIONS  INTER  CORP  t 
HQ  CASE/CBRC  1 
GOULD  INC/CSD  1 
HQ  AFSPACECOM/LKWD/STOP  32  1 
SVERDRUP/EGLIN  1 
HONEYWELL  INC/CLEARWATER  1 
TECHNOLOGY  SERVICE  CORP  1 
AEROSPACE/LOS  ANGELES  1 
SOFTWARE  ARCHITECTURE  &  ENGIN  1 
LORAL  SYSTEMS  GROUP/D/476-C2E  1 
NADC/CODE  7033  1 
UNISYS/PAOLA  RESEARCH  CTR  1 
SIRIUS  INC  1 
GENERAL  RESEARCH  CORP  1 
SOFTECH,  INC/R.L.  ZALKAN  1 
SOFTECH,  INC/R.B.  QUANRUD  1 
SOFTWARE  CERTIFICATION  INS  1 
SOFTWARE  CONSULTING  SPECIALIST  1 
SOFTWARE  PRODUCTIVITY  SOLUTIONS,  INC  1 
STAR-GLO  INDUSTRIES  INC  1 
NADC/CODE  50C  1 
WESTINGHOUSE/BALTIMORE  1 
MITRE  CORPORATION  1 
SYSCON  CORP/I.  WEBER  1 
SYSCON  CORP/C.  MORSE  1 
SYSCON  CORP/T.  GROBICKI  1 
AEROSPACE  C0RP0RATI0N/M-8-026  1 
TEXTRON  DEFENSE  SYSTEMS  1 
GENERAL  DYNAMICS/MZ  1774  1 
TIBURON  SYSTEMS,  INC  1 
TRW  DEFENSE  SYS  GROUP  1 
NASA  SPACE  STATION  1 
BALLISTIC  MSL  DEF  ADVANCED/ 

TECHNOLOGY  CENTER  1 
IBM  CORPORATION/FSD  1 
VISTA  CONTROLS  CORPORATION  1 
VITRO  CORPORATION  1 
NAVAL  RESEARCH  LABORATORY/CODE  5150  1 
CACI,  INC  1 
AFSC/PLR  5 
DIRECTOR  ADA  JOINT  PROGRAM  OFFICE  1 
MCDONNELL  DOUGLAS  ASTRONAUTICS/ 

E  434/106/2/MS22  7 
SDIO/S/PI  1 
ADVANCED  SOFTWARE  TECH  SPECIALTIES  1 
DTIC-DDAC  2 
AFCSA/SAMI  1 
AUL/LSE  1 


FTD/SDNF  1 
AFWAL/FIES/SURVIAC  1 
HQ  USAFE/INATW  1 
AFATL/CC  1 
AFATL/CA  1 
AFATL/DOIL  2 
6575  SCHOOL  SQUADRON  1 
IITRI  1 
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SUPPLEMENTARY 


INFORMATION 


* 


REPLY  TO 
,  ATTN  OF 


MNOI 


DEPARTMENT  OF  THE  AIR  FORCE 

WRIGHT  LABORATORY  (AFSC) 

EGLIN  AIR  FORCE  BASE,  FLORIDA,  32542-5434 


<J$6? 


13  Feb  92 


subject:  Removal  of  Distribution  Statement  and  Export-Control  Warning  Notices 


to:  Defense  Technical  Information  Center 
ATTN:  DTIC/HAR  (Mr  William  Bush) 

Bldg  5,  Cameron  Station 
Alexandria,  VA  22304-6145 

1.  The  following  technical  reports  have  been  approved  for  public  release  by 
the  local  Public  Affairs  Office  (copy  attached). 


Technical  Report  Number 

AD  Number 

1  .  88-18-Vol-4 

ADB 

120  251 

Z.  88-18-Vol-5 

ADB 

120  252 

3  88-I8-V0I-6 

ADB 

120  253 

-4.  88-25- Vol-l 

ADB 

120  309 

5.  88-25-Vol-2 

ADB 

120  310 

fc.  88-62-Vol-l 

ADB 

129  568 

1.  88-62-Vol-2 

ADB 

129  569 

88-62-Vol-3 

ADB 

129-570 

9-  85-93-Vol-l 

ADB 

102-654  u' 

40.  85-93-Vol-2 

ADB 

102-655 

At  85-93-Vol-3 

ADB 

102-656 

42.  88- 18- Vol-l 

ADB 

120  248 

IS.  88-18-Vol-2 

ADB 

120  249 

\4.  88-18-Vol-7 

ADB 

120  254 

IS.  88-I8-V0I-8 

ADB 

120  255^ 

44.  88-18-Vol-9 

ADB 

120  256 

17.  88-18-Vol-lO 

ADB 

120  257  H- 

U.88-I8-V0I-II 

ADB 

120  258 

l9.88-18-Vol-12 

ADB 

120  259 

2.  If  you  have  any  questions  regarding  this  request  call  me  at  DSN  872-4620. 


Chief,  Scientific  and  Technical 
Information  Branch 


1  Atch 

AFDTC/PA  Ltr,  dtd  30  Jan  92 


ERRMft 


OtnumiBffOFTttMIFOIICI 

HEADQUARTERS  AM  RORCE  DEVELOPMENT  TEST  CENTER  (AF8C) 
EQUN  AM  FORCE  BASft,  FLORIDA  32S42-M00 


REPLY  TO 
ATTN  OF 


PA  (Jim  Swinson,  882-3931) 
subject  Clearance  for  Public  Release 


30  January  1992 


to:  VfL/MNA 


The  following  technical  reports  have  been  reviewed  and  are  approved  for 
public  release:  AFATL-TR-88-18  (Volumes  1  &  2) ,  AFATL-TR-88-18  (Volumes 
4  thru  12) ,  AFATL-TR- 88-25  (Volumes  1  &  2) ,  AFATL-TR-88-62  (Volumes  1  thru  3) 
and  AFAUj-TR-85-93  (Volumes  1  thru  3) . 


5INIA  N.  PRIBYLA,  Lt  Col, 
Chief  of  Public  Affairs 


AFDTC/PA  92-039 


